Script to run on DHCPNAK

Thu Jul 20 18:35:26 UTC 2017

I see .. so the cable modem is acting like a router until the cable circuit totally comes up in which case it starts acting more like a bridge? 

Last idea: Any chance that the cable modems could be told not to serve DHCP under any circumstances? Like a default config? 

> From: "Mark Spring" <mspring at nktelco.com>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Sent: Thursday, July 20, 2017 2:28:29 PM
> Subject: Re: Script to run on DHCPNAK

> No, the 192 is a cable modem so not much control there. Any control I apply to
> it is lost until it boots...per cable labs spec.

> On Thu, Jul 20, 2017 at 2:27 PM perl-list < [ mailto:perl-list at network1.net |
> perl-list at network1.net ] > wrote:

>> Mark,

>> Is it the ISC server that is also handing out the 192.168.100.20 address or a
>> different DHCP server? If its all the same server, I'm thinking class {}
>> statements and allow members of "class"; would be the appropriate fix right
>> inside the DHCP config...

>> If it is a different DHCP server that is ALSO ISC that you could modify, you
>> could use class {} statements in there to cause it to ignore booting from
>> clients it shouldn't serve.

>>> From: "Mark Spring" < [ mailto:mspring at nktelco.com | mspring at nktelco.com ] >
>>> To: "Users of ISC DHCP" < [ mailto:dhcp-users at lists.isc.org |
>>> dhcp-users at lists.isc.org ] >

>>> Sent: Thursday, July 20, 2017 8:53:11 AM
>>> 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 < [ mailto:perl-list at network1.net |
>>> 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" < [ mailto:mspring at nktelco.com | mspring at nktelco.com ] >
>>>>> To: "Users of ISC DHCP" < [ mailto:dhcp-users at lists.isc.org |
>>>>> 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 [ http://10.4.0.1/ | 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 < [ mailto:perl-list at network1.net |
>>>>> 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
>>>>>> [ mailto:dhcp-users at lists.isc.org | dhcp-users at lists.isc.org ]
>>>>>> [ https://lists.isc.org/mailman/listinfo/dhcp-users |
>>>>>> https://lists.isc.org/mailman/listinfo/dhcp-users ]

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

>>>>> Phone: 1-888-NKTELCO
>>>>> Fax: [ tel:(419)%20753-2950 | 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.

>>>>> _______________________________________________
>>>>> dhcp-users mailing list
>>>>> [ mailto:dhcp-users at lists.isc.org | dhcp-users at lists.isc.org ]
>>>>> [ https://lists.isc.org/mailman/listinfo/dhcp-users |
>>>>> https://lists.isc.org/mailman/listinfo/dhcp-users ]
>>>> _______________________________________________
>>>> dhcp-users mailing list
>>>> [ mailto:dhcp-users at lists.isc.org | dhcp-users at lists.isc.org ]
>>>> [ https://lists.isc.org/mailman/listinfo/dhcp-users |
>>>> 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.

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

> Mark Spring
> Information Systems Manager

> 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.

> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170720/8734af24/attachment-0001.html>