diff options
author | Thomas Haller <thaller@redhat.com> | 2019-02-06 18:13:20 +0100 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2019-02-15 11:41:06 +0100 |
commit | 13f1fd03761519cdaab5aed505a5308bba3eb217 (patch) | |
tree | 182db001d56ff870a658cacbc5cc7d994fb4d7f1 /test/test-network | |
parent | Merge pull request #11636 from yuwata/network-in-addr-is-null (diff) | |
download | systemd-13f1fd03761519cdaab5aed505a5308bba3eb217.tar.xz systemd-13f1fd03761519cdaab5aed505a5308bba3eb217.zip |
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.
Diffstat (limited to 'test/test-network')
0 files changed, 0 insertions, 0 deletions