Script to run on DHCPNAK

Patrick Trapp ptrapp at nex-tech.com
Thu Jul 20 13:24:42 UTC 2017


We have had a similar issue with some of our residential gateways, which sound like they are serving a similar purpose to what you are seeing. I’m not familiar with their configuration, but the solution for us has been a different configuration on the gateways so that they won’t offer an address to the specific equipment in question. I’m not certain how our field techs are differentiating between the devices that the gateway should offer an address to and those that it should not offer an address to.

If that sounds remotely helpful, I can try to get more information or we can discuss offline (it’s not an ISC DHCP issue at that point) and see if there are more parallels to our situations.

Patrick

From: dhcp-users [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Mark Spring
Sent: Thursday, July 20, 2017 7:53 AM
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Subject: Re: Script to run on DHCPNAK

The trouble is that the end device boots too quick and grabs the 192 address from the modem(cable labs spec) then moments later it halts and asks for all the information that would normally be in the DHCP options. The lease from the modem expires, it requests...server NAK's it. It then gets all the proper info but the client doesn't read in all of the options. In a perfect world I have advised the vendor to read in the options and continue with the client. In the real world, I am trying to setup things so when I see a NAK, I execute a script...if it matches an OUI then I lookup the IP that it received, SSH into the client and reboot it. The modem is online and everything starts up normal. We are essentially building a reboot script into the client where it reboots if it fails to receive options the first time around.

Hope this helps, thanks for replying!


Mark Spring
Information Systems Manager

On Thu, Jul 20, 2017 at 8:45 AM, perl-list <perl-list at network1.net<mailto:perl-list at network1.net>> wrote:
Mark,

That is completely normal.  The device 00:03:e6:6f:42:14 previously had an address of 192.168.100.20 and attempted to renew such address.  Apparently that address is not valid on the network your DHCP server is on.  So, a NAK was sent followed by a discover from the client.  The client and server then negotiated a 10.4.2.191 address.

What is the actual problem that you are having as I am not sure this has anything to do with it...
________________________________
From: "Mark Spring" <mspring at nktelco.com<mailto:mspring at nktelco.com>>
To: "Users of ISC DHCP" <dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>>
Sent: Thursday, July 20, 2017 8:31:30 AM
Subject: Re: Script to run on DHCPNAK
isc, just one server  here is an example
Jul 19 10:04:36 dhcp dhcpd: DHCPREQUEST for 192.168.100.20 from 00:03:e6:6f:42:14 via 10.4.0.1<http://10.4.0.1>: wrong net
Jul 19 10:04:36 dhcp dhcpd: DHCPNAK on 192.168.100.20 to 00:03:e6:6f:42:14 via 10.4.0.1
Jul 19 10:04:39 dhcp dhcpd: DHCPDISCOVER from 00:03:e6:6f:42:14 via 10.4.0.1
Jul 19 10:04:40 dhcp dhcpd: DHCPOFFER on 10.4.2.191 to 00:03:e6:6f:42:14 via 10.4.0.1
Jul 19 10:04:40 dhcp dhcpd: DHCPREQUEST for 10.4.2.191 (192.168.100.3) from 00:03:e6:6f:42:14 via 10.4.0.
Jul 19 10:04:40 dhcp dhcpd: DHCPACK on 10.4.2.191 to 00:03:e6:6f:42:14 via 10.4.0.1



Mark Spring
Information Systems Manager

On Thu, Jul 20, 2017 at 8:22 AM, perl-list <perl-list at network1.net<mailto:perl-list at network1.net>> wrote:

Are the NAK and ACK coming from the same server?  Can you post example log messages of the NAK and ACK and related communication?  I assume this is ISC DHCP that we are speaking of and not some proprietary DHCP server?

________________________________

I am having some issues with network gear, and while arguing with vendors about who's problem it really is..I noticed that my device receives a NAK before it receives the proper IP address from our server(when the gear comes back online). If I can track this down in the logs then I can look for the ACK that follows, login to the device and reboot it properly.

___


_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/dhcp-users


NKTelco
301 W. South St.
New Knoxville, OH 45871

Phone: 1-888-NKTELCO
Fax: 419-753-2950<tel:(419)%20753-2950>

This message and the file(s) attached are confidential and proprietary
information of NKTelco for the sole use of the intended recipient. Any
unauthorized review, distribution, disclosure, copying, use, or
dissemination, either whole or in part, is strictly prohibited. Do not
transmit these documents, in any form, to any third party without the
expressed written permission of NKTelco.

_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/dhcp-users


NKTelco
301 W. South St.
New Knoxville, OH 45871

Phone: 1-888-NKTELCO
Fax: 419-753-2950

This message and the file(s) attached are confidential and proprietary
information of NKTelco for the sole use of the intended recipient. Any
unauthorized review, distribution, disclosure, copying, use, or
dissemination, either whole or in part, is strictly prohibited. Do not
transmit these documents, in any form, to any third party without the
expressed written permission of NKTelco.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170720/eb0e188b/attachment-0001.html>


More information about the dhcp-users mailing list