Hi, On Thu, 2014-10-02 at 20:05 +0200, Tom Gundersen wrote: > > The DHCPv4 header is the same format no matter what the LL address size, > > but for non-ethernet the hlen is 0 and the chaddr is zeroed. The BPF is > > seeded with an hlen of 0 and a valid ETH_ALEN sized buffer of all zeros. > > So both the hlen and chaddr comparisons comparison should succeed. > > > > Does that make sense? I might have missed something too though... > > So that sounds fine, but my concern was: are we guaranteed that all > implementations properly zero out the remaining bytes past the hlen > first ones? Sounds weird to reject a package if it has hlen == 0 and > garbage in chaddr, or is the zeroing something we can rely on? (In > that case I guess we should extend the check to check all 16 bytes, > and not only the 6 first ones to make it truly agnostic). > > Patrik, any thoughts?
At least RFC2131 says that the DHCP server uses the 'chaddr' supplied by the client without considering hardware address length in 'hlen'. Apparently both client and server need to use the same hardware addressing, so 'hlen' on both ends match anyway. Since our client implementation has properly zeroed out the DHCP header before filling it with information, there should be no problem just comparing all 16 bytes of 'chaddr' where the first 'hlen' bytes is the hardware address and the rest should definitely be zero, since that was what was sent in the first place. Currently the client side implementation only checks that the N first bytes containing the MAC address, so technically that is a bug. For a hardware address length of zero, 'chaddr' should match what the client sent, in our case 16 bytes of zeroes. Cheers, Patrik _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel