[systemd-devel] [PATCH] sd-dhcp-client: support non-Ethernet hardware addresses

[Patrik Flykt]

	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