NAK Message ignored

David W. Hankins David_Hankins at
Thu May 22 15:07:18 UTC 2008

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
> Discover comes in.
> May 21 15:27:57 netreg1 dhcpd: DHCPREQUEST for (
> from 00:e0:4c:0a:34:dc via 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  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

> May 21 15:27:57 netreg1 dhcpd: DHCPNAK on to
> 00:e0:4c:0a:34:dc via
> Server NAKs.
> May 21 15:27:58 netreg1 dhcpd: DHCPOFFER on to
> 00:e0:4c:0a:34:dc (D2WL8P91) via
> 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
> (00:10:dc:dd:08:94) via
> May 21 15:33:21 netreg1 dhcpd: DHCPACK to
> (00:10:dc:dd:08:94) via
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Should not be ACK'ing

probably a DHCPINFORM?  especially since there are two.

Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?
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

More information about the dhcp-users mailing list