Context is that, in a previous MR, I needed to add the client ID option to bootp messages for RADIUS authentication. But the client ID was not recognized. And the reason was that a leading option added to the bootp packet was eating all the remaining bytes as you can see in this wireshark capture:
The leading option was added by forge and it was meant to be in fact the DHCP magic cookie. But you can see in the same capture that the DHCP cookie is already added just before these bytes. Kea correctly reads the DHCP magic cookie from the right place, but at the same time it expects this four-byte sequence and it's supposed to be either vendor options or magic cookie, or both. Comment is unclear. Quote from Kea code which complains if it is left out:
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.");
}So what I did was add a zero padding, and it appeases wireshark:
And also Kea correctly recognizes it as a bootp message and it also recognizes the options that follow.
The reason tests worked so far, was because we didn't needed any bootp options before and forge didn't check for them. It only checked that options are not found in the message.
Also, after this was fixed, bootp HA tests started failing because it was suddenly seeing the same clients as different clients because of the added client ID and so they were getting different leases. I fixed this by not expecting a certain lease, just like with the v4 counterpart, but checking them afterwards.
The try-except-pass is because bootp don't have a valid lifetime option.