[dhcp] Fall back to using the hardware address to populate the chaddr field
authorMichael Brown <mcb30@etherboot.org>
Tue, 11 Aug 2009 22:44:04 +0000 (23:44 +0100)
committerMichael Brown <mcb30@etherboot.org>
Tue, 11 Aug 2009 23:27:08 +0000 (00:27 +0100)
commit444d5550a70fef7735ed1821a0e6f8410f0e03ef
treee27ed2974556073e94462b5cde1192aba9776cd0
parent4eab5bc8ca6b66dc965cf188dd4577ad19c5b879
[dhcp] Fall back to using the hardware address to populate the chaddr field

For IPoIB, the chaddr field is too small (16 bytes) to contain the
20-byte IPoIB link-layer address.  RFC4390 mandates that we should
pass an empty chaddr field and rely on the DHCP client identifier
instead.  This has many problems, not least of which is that a client
identifier containing an IPoIB link-layer address is not very useful
from the point of view of creating DHCP reservations, since the QPN
component is assigned at runtime and may vary between boots.

Leave the DHCP client identifier as-is, to avoid breaking existing
setups as far as possible, but expose the real hardware address (the
port GUID) via the DHCP chaddr field, using the broadcast flag to
instruct the DHCP server not to use this chaddr value as a link-layer
address.

This makes it possible (at least with ISC dhcpd) to create DHCP
reservations using host declarations such as:

    host duckling {
        fixed-address 10.252.252.99;
        hardware unknown-32 00:02:c9:02:00:25:a1:b5;
    }
src/include/gpxe/dhcp.h
src/net/udp/dhcp.c
src/usr/dhcpmgmt.c