Kea refuses to make DHCP offer with ERROR: MBZ nibble 0x6 != 0

[jamtur01]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

Caveat - I am not sure if this is a bug with Kea but ....

I have some Hitron HTEM4 Moca adaptors. They default to doing DHCP for IP addresses. I couldn't work out why they weren't getting DHCP addresses so I tcpdump'ed the DHCP requests and I see:

root@opnsense:~ # tcpdump -vv -i igc1 port 67 or port 68
tcpdump: listening on igc1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:33:48.200149 IP (tos 0x0, ttl 64, id 434, offset 0, flags [none], proto UDP (17), length 387)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from dc:36:0c:d6:68:a8 (oui Unknown), length 359, xid 0x225603cb, secs 28, Flags [Broadcast] (0x8000)
          Client-Ethernet-Address dc:36:0c:d6:68:a8 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Request
            Requested-IP (50), length 4: 192.168.1.133
            Subnet-Mask (1), length 4: 255.255.255.0
            Default-Gateway (3), length 4: opnsense
            Domain-Name-Server (6), length 4: opnsense
            Lease-Time (51), length 4: 4000
            Parameter-Request (55), length 6:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
              Unknown (125), Vendor-Option (43)
            Server-ID (54), length 4: opnsense
            Hostname (12), length 9: "VSCO-68A8"
            FQDN (81), length 6: [ERROR: MBZ nibble 0x6 != 0] [SN] 110/105 "che"
            Vendor-Class (60), length 12: "dslforum.org"
            Unknown (125), length 36: 3561,520160836,1127429680,1124207684,1127429680,1128543798,943798275,120664369,758724921
18:33:49.163643 IP (tos 0x0, ttl 64, id 2639, offset 0, flags [none], proto UDP (17), length 387)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from dc:36:0c:d6:60:a0 (oui Unknown), length 359, xid 0x22535935, secs 1148, Flags [Broadcast] (0x8000)
          Client-Ethernet-Address dc:36:0c:d6:60:a0 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Request
            Requested-IP (50), length 4: 192.168.1.123
            Subnet-Mask (1), length 4: 255.255.255.0
            Default-Gateway (3), length 4: opnsense
            Domain-Name-Server (6), length 4: opnsense
            Lease-Time (51), length 4: 4000
            Parameter-Request (55), length 6:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
              Unknown (125), Vendor-Option (43)
            Server-ID (54), length 4: opnsense
            Hostname (12), length 9: "VSCO-60A0"
            FQDN (81), length 6: [ERROR: MBZ nibble 0x6 != 0] [SN] 110/105 "che"
            Vendor-Class (60), length 12: "dslforum.org"
            Unknown (125), length 36: 3561,520160836,1127429680,1124207684,1127429680,1128543798,809578499,120664369,758724921

Note the:

FQDN (81), length 6: [ERROR: MBZ nibble 0x6 != 0] [SN] 110/105 "che"

Kea refuses to issue an address. I tested ISC, and it works (correctly?) and issues an address. I presume its RFC validation is more relaxed. I did look for a way to configure Kea to be more accepting, but I couldn't see anything relevant.

The problem may be that the HTEM4s should be better behaved, but I figured it was worth reporting as an FYI, at least.

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 23.7.8 (amd64).OPNsense 24.7.9_1-amd64
FreeBSD 14.1-RELEASE-p6
OpenSSL 3.0.15

[AdSchellevis]

We should probably consider offering other logging levels to trace issues like these, from a console, you could try to set the logger to DEBUG in /usr/local/etc/kea/kea-dhcp4.conf and restart kea using /usr/local/etc/rc.d/kea restart. If kea ignores the message in full, there is a chance debug output would explain the reason why.

The tcpdump message seems to complain about option 81 not being compliant to RFC 4702 (the-tcpdump-group/tcpdump@e248133), digging a bit further seems to indicate an upstream issue (https://gitlab.isc.org/isc-projects/kea/-/issues/3289)