Kea does not accept BOOTP packets without options
BOOTP packets that don't have any options, or more specifically, only the end option, code 255, are not accepted by Kea. The following exception is thrown:
src/lib/dhcp/pkt4.cc:166-171
if (buffer_in.getLength() == buffer_in.getPosition()) {
// this is *NOT* DHCP packet. It does not have any DHCPv4 options. In
// particular, it does not have magic cookie, a 4 byte sequence that
// differentiates between DHCP and RFC 951 BOOTP packets.
isc_throw(InvalidOperation, "Received BOOTP packet without vendor information extensions.");
}
Discovered while starting testing BOOTP with options in forge and seeing that the options aren't recognized. For a long time, we've been testing BOOTP without any intended options, but there was a cookie placed at the beginning of the variable section of the packet. That section was interpreted as a set of options. You can see in the following screenshot that the first byte of the cookie 0x63 is considered option code 99. And also that the real DHCP cookie is just before the options section placed there by scapy.
What we did in forge to circumvent this situation and not have option 99 eat all of the other options is put padding of four bytes instead of the fake cookie. Kea reads the cookie from the correct place, and added options after that are recognized, and Wireshark no longer considers the packet malformed.
So, is there a reason why it expects vendor information extensions? Are four bytes the minimum you can get in a vendor information extension? And why does the comment mention something else, the cookie?