On 8/29/05, Stephan Leemburg <[EMAIL PROTECTED]> wrote: > Hello @misc, > > I am in the unfortunate position to have been donated 2 > windowsnetworks, due to a merger of our company. > As a unix/macos (which now is unix) only site, I'm confronted with > very strange things. > > At the moment I'm experiencing an unwilling windows client. It has an > DHCP Client Identifier configured and in it's DHCPDISCOVER it is > overwriting the chaddr field (which should contain it's hardware > address) with a 16 bytes long Client Identifier. It has it's hlen > field set to this 16 bytes, but the hardware type is set to 1, which > is Ethernet. And as we all know Ethernet addresses are not 16 bytes > long. > > So now my generated dhcpd.conf does not accept this. I have put in an > option dhcp-client-identifier, but still dhcpd looks at the hardware > address and refuses it. Deleting the hardware ethernet line, leaving > only the dhcp-client-identifier also does not solve the problem. > > Has anyone ever had similar experiences and know how to solve this? > > I also think a patch to dhcpd would be in place. I will write one > tomorrow and submit it. The dhcpd server will have to look at the > chaddr/type and hlen and if the combination is wrong (a 16 byte > ethernet address, which matches the client identifier value), then it > should either replace the chaddr with the correct ethernet address or > just ignore the message, which as far as I can tell is violating the > rfc. > > -- > Stephan Leemburg > >
Windows DHCP client always has been and probably always will be broken. Look here: http://lists.debian.org/debian-laptop/2002/02/msg00357.html The problem was well documented in NetWare 5 DHCP server docs. After watching the debug screen on one of these, it looks like the Windows client ignors DHCP NACK packets for requested IP addresses. YMMV
