]> git.ipfire.org Git - thirdparty/systemd.git/commit
dhcp: ignore padding of 'chaddr' in DHCP server response
authorThomas Haller <thaller@redhat.com>
Wed, 6 Feb 2019 17:13:20 +0000 (18:13 +0100)
committerLennart Poettering <lennart@poettering.net>
Fri, 15 Feb 2019 10:41:06 +0000 (11:41 +0100)
commit13f1fd03761519cdaab5aed505a5308bba3eb217
tree182db001d56ff870a658cacbc5cc7d994fb4d7f1
parent8e6b3f49fea2ca9bb306cfa66d1e9cd7758b1799
dhcp: ignore padding of 'chaddr' in DHCP server response

The "chaddr" field is 16 bytes long, with "hlen" being the
length of the address.

https://tools.ietf.org/html/rfc2131#section-4.3.1 says:

    The server MUST return to the client:

    ...

    o Any parameters specific to this client (as identified by
      the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
      or DHCPREQUEST message), e.g., as configured by the network
      administrator,

It's not clear, whether only the first 'hlen' bytes of 'chaddr'
must correspond or all 16 bytes.

Note that https://tools.ietf.org/html/rfc4390#section-2.1 says for IPoIB

    "chaddr" (client hardware address) field MUST be zeroed.

with having "hlen" zero. This indicates that at least in this case, the
bytes after "hlen" would matter.

As the DHCP client always sets the trailing bytes to zero, we would expect
that the server also replies as such and we could just compare all 16 bytes.
However, let's be liberal and accept any padding here.

This in practice only changes behavior for infiniband, where we
previously would enforce that the first ETH_ALEN bytes are zero.
That seems arbitrary for IPoIB. We should either check all bytes or
none of them. Let's do the latter and don't enforce RFC 4390 in this
regard.
src/libsystemd-network/dhcp-network.c
src/libsystemd-network/sd-dhcp-client.c