DHCPNAK query

[David W. Hankins]

On Tue, Mar 23, 2010 at 06:47:38AM -0700, Friesen, Don SSBC:EX wrote:
>    Prior to 4.1.1 we would see a unicast 
> REQUEST come in at t1 (RENEW) from the remote 
> client, and have it logged both on the sniffer 
> and the DHCP server that received it.  The 
> DHCP server would log a NAK and then hang.  
> The NAK would not appear on the sniffer.  
> This was due to the bug in 4.1.0 that was 
> fixed in 4.1.1.

You're describing a bug with our interface code, our handler
functions when using Solaris' DLPI interface to send raw sockets.
The bug actually was a problem decoding the MAC address of an
interface in Solaris when using DHCPv4; it would derive a garbage
value and attempt to use that as a source MAC address in DLPI to
transmit the DHCPNAK.  This causes DLPI to stop delivering packets
from clients as well as being unable to transmit the DHCPNAK.

The OP has said they are running Debian, so there is no valid reason
why a client moving from one network to another and appropriately
entering INIT-REBOOT behind an authoritative server would not be
met with a DHCPNAK, even on 4.1.0.

I would expect the server would log its reason for not responding on
the log line for the DHCPREQUEST packet in question.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100323/2ce23c38/attachment.bin>