#1188 Stalled bug 560361 -- requesting intervention
Closed None Opened 7 years ago by philipp.

= phenomenon =

A bug has been filed, and extensively documented and discussed.

A solution has been found and tested, with results documented as well.

Yet this bug has not moved to closure, in nearly 4 years.

See: https://bugzilla.redhat.com/show_bug.cgi?id=560361

= background analysis =

In many bridged environments (Wifi-to-Ethernet, Ethernet-to-DOCSIS, Ethernet-to-DSL [PPPoE]) the bridge might mangle the DHCP client's MAC address, replacing it with its own.

The workaround is to always use a client-id derived from the hw type and the hw address, as per RFC-3315 Section 9.4:

{{{
9.4. DUID Based on Link-layer Address [DUID-LL]

This type of DUID consists of two octets containing the DUID type 3,
a two octet network hardware type code, followed by the link-layer
address of any one network interface that is permanently connected to
the client or server device. For example, a host that has a network
interface implemented in a chip that is unlikely to be removed and
used elsewhere could use a DUID-LL. The hardware type MUST be a
valid hardware type assigned by the IANA, as described in RFC 826
[14]. The hardware type is stored in network byte order. The
link-layer address is stored in canonical form, as described in RFC
2464 [2]. The following diagram illustrates the format of a DUID-LL:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               3               |    hardware type (16 bits)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.             link-layer address (variable length)              .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The choice of network interface can be completely arbitrary, as long
as that interface provides a unique link-layer address and is
permanently attached to the device on which the DUID-LL is being
generated. The same DUID-LL SHOULD be used in configuring all
network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate the DUID.

DUID-LL is recommended for devices that have a permanently-connected
network interface with a link-layer address, and do not have
nonvolatile, writable stable storage. DUID-LL MUST NOT be used by
DHCP clients or servers that cannot tell whether or not a network
interface is permanently attached to the device on which the DHCP
client is running.
}}}

= implementation recommendation =

As per the bug, recommending that the file /etc/dhcp/dhclient.conf be added to the RPM payload and that it include the contents:

{{{

required in environments where a bridge might be clobbering the forwarded

packet's MAC address (common in Wifi, Docsis, or ADSL bridging scenarios)

send dhcp-client-identifier = hardware;
}}}


I see the bug has had progress. Is this fixed?

The bug is closed->errata. Closing this as well.

If there's still some issue here, do reopen.

Replying to [comment:1 toshio]:

I see the bug has had progress. Is this fixed?

I was able to take the server down long enough to test the fix. Needed to do an F18 mockbuild of the GIT contents via fedpkg (from 'master'), and that seems to have installed and be working adequately.

Thanks.

Login to comment on this ticket.

Metadata