Thomas Haller
13f1fd0376
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.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.