Script to run on DHCPNAK

[Bob Harold]

On Thu, Jul 20, 2017 at 9:49 AM, Mark Spring <mspring at nktelco.com> wrote:

> Patrick,
>
> Cable labs spec mandates that they must hand out an IP before they come
> online. I've fought with them all I can, the new gear boots too quickly and
> the new modems boot too slow. I'm just trying to find a way to trigger from
> the NAK. Certainly not a isc issue, just trying to find a good trigger!
>
> Mark
>
> On Thu, Jul 20, 2017 at 9:46 AM Mark Spring <mspring at nktelco.com> wrote:
>
>> Nope, this is normal.
>>
>> On Thu, Jul 20, 2017 at 8:45 AM perl-list <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>
>>> *To: *"Users of ISC DHCP" <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>
>>> 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.
>>>>
>>>> NKTelco
>>> 301 W. South St.
>>> New Knoxville, OH 45871
>>>
>>> Phone: 1-888-NKTELCO
>>> Fax: 419-753-2950 <(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.
>>>
>>> --
>
> Mark Spring
> Information Systems Manager
>
> NKTelco
> 301 W. South St.
> New Knoxville, OH 45871
>
> Phone: 1-888-NKTELCO
> Fax: 419-753-2950 <(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.
>
>
I don't see any "on nak" event, so you could look into:
- log to syslog, and see if syslog can trigger on a string, or if it can
write logs without long buffering.
- set up an "on commit" event and try to match one of your devices getting
a wrong address.  Have the event call an outside script to do the reboot.
You will want to start a separate process and return control to the DHCP
server quickly, not have it wait for a reboot to finish.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170720/f112fc8a/attachment-0001.html>