NAK Message ignored

[David W. Hankins]

On Wed, May 21, 2008 at 04:04:49PM -0700, Keith wrote:
> May 21 15:27:57 netreg1 dhcpd: DHCPDISCOVER from 00:e0:4c:0a:34:dc
> (D2WL8P91) via 69.176.178.1
> 
> Discover comes in.
> 
> May 21 15:27:57 netreg1 dhcpd: DHCPREQUEST for 192.168.0.115 (0.0.0.0)
> from 00:e0:4c:0a:34:dc via 69.176.178.1: wrong network.
> 
> But the client appears to also send in a Request at the same time.

my money is on "rogue DHCP server".

it's kind of problematic that the rogue dhcp server appears to have
set its server-identifier to 0.0.0.0.  this makes it harder to
track down.  you can either use a client that sets the broadcast bit
to get the rogue server to broadcast and trace it back by mac address
on the switch fabric, or you can put a sniffer somewhere near the
client to intercept the unicast replies to the client's mac.  i think
vista sets the broadcast bit by default, and as we've discovered there
is a registry setting in vista to control this, i don't know if that
registry setting exists in earlier versions of windows.


current epistemology on the running of large customer-interfacing
networks using DHCP is to apply filters at layer 2 to ensure that
DHCP client traffic can move upstream, and DHCP server traffic can
move downstream.  this can be simply enforced by port number, and
keeps customer-network DHCP servers hooked up to the wrong interface
from sending replies to their neighbors.  filtering out the rogue
servers seems to keep anyone from noticing a problem in the first
place.


> May 21 15:27:57 netreg1 dhcpd: DHCPNAK on 192.168.0.115 to
> 00:e0:4c:0a:34:dc via 69.176.178.1
> 
> Server NAKs.
> 
> May 21 15:27:58 netreg1 dhcpd: DHCPOFFER on 69.176.178.61 to
> 00:e0:4c:0a:34:dc (D2WL8P91) via 69.176.178.1
> 
> But sends back an Offer, which the client appears to ignore because the
> client sends a Discover again a few mins later:

the client is paying attention to the nak.  by the time it receives
the offer it's moved out of selecting anyway.

> May 21 15:33:18 netreg1 dhcpd: DHCPACK to 192.168.0.117
> (00:10:dc:dd:08:94) via 69.176.178.1
> May 21 15:33:21 netreg1 dhcpd: DHCPACK to 192.168.0.117
> (00:10:dc:dd:08:94) via 69.176.178.1
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Should not be ACK'ing 192.168.0.117.

probably a DHCPINFORM?  especially since there are two.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins