Malformed DHCP potentially related to Option 81

Describe the bug

We recently migrated from isc-dhcpd to kea (Kea DHCPv4 server, version 2.0.1 (stable)). We noticed that some older embedded devices were unable to complete the DORA process. These older devices had no problems DHCP'ing using isc-dhcpd-4.2.7. Using Wireshark we confirmed the server does receive the DISCOVERs, but Wireshark labels the packet as "malformed". I have attached the single packet to this report. As an aside, older versions of Wireshark do not label the packet as malformed.

There are two issues I'd like to report.

1. We added debug output for kea-dhcp4.bad-packets all the way up to 99, and kea never logged an event related to this potentially malformed packet. So we also added debug output for kea-dhcp4.packets all the way up to 50. There we get a single line confirming the buffer was received, but nothing after that.

2. Perhaps Kea should be able to actually accept whatever deformity this packet has, as it seems like isc-dhcpd had no issues accepting it.

To Reproduce

Steps to reproduce the behavior:

1. Run Kea (dhcpv4) with the following config

"loggers": [{
		"name": "kea-dhcp4",
		"output_options": [
		    {"output": "syslog:local6"}],
		"severity": "INFO"},
	    {"name": "kea-dhcp4.bad-packets",
		"output_options": [
		    {"output": "/var/log/kea/badpackets.log"}],
		"severity": "DEBUG",
		"debuglevel": 99},
	    { "name": "kea-dhcp4.packets",
		"output_options": [
		    {"output": "/var/log/kea/allpackets.log"}],
		"severity": "DEBUG",
		"debuglevel": 50}],

2. Client sends a packet formatted like the attached packet malformed_dhcp.pcap
3. The server then logs receipt of the buffer, but then nothing else

2022-01-05 10:09:25.416 DEBUG [kea-dhcp4.packets/15803.140131142945216] DHCP4_BUFFER_RECEIVED received buffer from 128.180.184.251:67 to 128.180.2.9:67 over interface bond0

Expected behavior

Ideally, I expect to be able to massage Kea into serving DHCP to these devices, but if that is deemed impossible, Kea should log the receipt of the bad packet in the badpacket logger with some explanation of why it's bad.

Environment:

• Kea version: version 2.0.1 (stable)
• OS: Debian 10.11, 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2
• We used the sic-provided packages with some custom hooks
• Hooks being used:

        "library": "/home/kea/libfingerprint.so",
        "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
        "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so",
        "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
        "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_legal_log.so"

Additional Information

This is a repeatable issue and we're happy to collect/provide additional detail if necessary. In reading some previous bug reports I noticed similar behavior related to option 81 flags which is why I think this is an option 81 issue. Devices similar in nature that are not sending option 81 do not exhibit this behavior. Looking at the specific packet I attacked, in Option 81 of the 4 flags (NEOS), our client is setting the E and S flags to 1. For those just wanting to see the Option 81 hex data:

0120   03 06 74 01 01 51 0a 05 00 00 43 41 42 44 35 30
0130   44 3d 07 01 00 20 4a ab d5 0d ff 00 00 00 00 00
0140   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0150   00 00 00 00 00 00

• 51 = Option 81
• 0a = 10 bytes
• 05 = NEOS
• 00 = A-RR result
• 00 = PTR-RR result
• 43 41 42 44 35 30 44 = should be the FQDN?