If the server sends a packet with multiple instances of the same option, they are concatenated during n_dhcp4_incoming_linearize() and evaluated as a single option as per section 7 of RFC 3396.
However, there are broken server implementations that send self-contained options in multiple copies. They are reassembled to form a single instance by the nettools client, which then fails to parse them because they have a length greater than the expected one.
This problem can be reproduced by starting a server with:
dnsmasq --bind-interfaces --interface veth1 -d--dhcp-range=172.25.1.100,172.25.1.200,1m--dhcp-option=54,172.25.1.1
In this way dnsmasq sends a duplicate option 54 (server-id) when the client requests it in the 'parameter request list' option, as dhcp=systemd and dhcp=nettools currently do.
While this is a violation of the RFC by the server, both isc-dhcp and systemd-networkd client implementations have mechanisms to deal with this situation. dhclient simply takes the first bytes of the aggregated option. systemd-networkd doesn't follow RFC 3396 and doesn't aggregate multiple options; it considers only the last occurrence of each option.
Change the parsing code to accept options that are longer than necessary.
1cbf9d22a n-dhcp4: accept options that are longer than requested
shared/n-dhcp4/src/n-dhcp4-incoming.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)