DHCPNAK query

[Friesen, Don SSBC:EX]

>Thank you for the vital information. 
>I was debugging this issue and i found 
>that nak_lease do not unicast. Also i was 
>not receiving any request packets from the  
>remote subnet client. Which makes sense 
>because REBIND is not happened.
>Do u see that this is the expected behaviour.

  From times prior to our implementing ISC 
DHCP, when we used Sun's old NIS+ based 
service, we port mirrored our DHCP servers 
to a sniffer to log the DHCP traffic.  This 
helped us see things like when customers 
installed their own DHCP servers that were 
responding on the remote subnets (and then 
complain that our DHCP servers weren't 
working).  I mention that because it held 
clues to debugging what was happening to 
the NAKs.

   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.

   Unfortunately I can't tell you exactly what 
the behaviour of 4.1.1 is, but I expect that 
the sniffer would log a local broadcast NAK 
in response to the unicast REQUEST.  The 
unicast REQUESTs and broadcast NAKs would 
continue throughout the renewal interval 
until t2 (REBIND) when the client would switch 
to a broadcast REQUEST, and the relay agent 
would step in to relay the request.  
Nak_lease would then reply to the relay agent 
with a NAK that would reach the client.

   The reason I can't tell you what happens 
with 4.1.1 is that my copy includes a unicast 
NAK patch (which ISC does not recommend using).

Don.