summaryrefslogtreecommitdiffstats
path: root/test/test-network/systemd-networkd-tests.py
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2019-02-06 18:13:20 +0100
committerLennart Poettering <lennart@poettering.net>2019-02-15 11:41:06 +0100
commit13f1fd03761519cdaab5aed505a5308bba3eb217 (patch)
tree182db001d56ff870a658cacbc5cc7d994fb4d7f1 /test/test-network/systemd-networkd-tests.py
parentMerge pull request #11636 from yuwata/network-in-addr-is-null (diff)
downloadsystemd-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/systemd-networkd-tests.py')
0 files changed, 0 insertions, 0 deletions