n-dhcp4: accept options that are longer than requested

System Internals / NetworkManager - Beniamino Galvani [redhat.com] - 25 January 2020 10:31 EST

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.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/324

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(-)

Upstream: cgit.freedesktop.org


  • Share