ISC DHCP Users

Script to run on DHCPNAK

Classic

List

Threaded

16 messages Options

Mark Spring

Script to run on DHCPNAK

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.

I wrote a script to try and tail the log file with bash and I have been able to pick off the traffic but the buffer when tailing in bash leaves me with a case where time before the device is handled is indefinite.

I have read about the "on commit" in the config and that doesn't seem to help, the expiry and other options don't seem to fit my needs either.

I'm not necessarily committed to BASH, it just seemed to be the quickest go to without a lot of fluff...considered PERL PHP or Python. Don't have a lot of experience with one particular language, just use what works for each scenario.

Let me know where I can fill in blanks!

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

perl-list

Re: Script to run on DHCPNAK

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Mark Spring

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: 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 <[hidden email]> 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
[hidden email]
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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

perl-list

Re: Script to run on DHCPNAK

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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Mark Spring

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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

Phone: 1-888-NKTELCO
Fax: <a href="tel:(419)%20753-2950" value="+14197532950" target="_blank">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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Patrick Trapp

RE: Script to run on DHCPNAK

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:[hidden email]] On Behalf Of Mark Spring
Sent: Thursday, July 20, 2017 7:53 AM
To: Users of ISC DHCP <[hidden email]>
Subject: Re: Script to run on DHCPNAK

Hope this helps, thanks for replying!

Mark Spring

Information Systems Manager

On Thu, Jul 20, 2017 at 8:45 AM, perl-list <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

NKTelco
301 W. South St.

New Knoxville, OH 45871

Phone: 1-888-NKTELCO

Fax: <a href="tel:(419)%20753-2950" target="_blank">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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Mark Spring

Re: Script to run on DHCPNAK

In reply to this post by perl-list

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 <[hidden email]> wrote:

Nope, this is normal.

On Thu, Jul 20, 2017 at 8:45 AM perl-list <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Bob Harold

Re: Script to run on DHCPNAK

On Thu, Jul 20, 2017 at 9:49 AM, Mark Spring <[hidden email]> 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 <[hidden email]> wrote:
Nope, this is normal.

On Thu, Jul 20, 2017 at 8:45 AM perl-list <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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: <a href="tel:(419)%20753-2950" value="+14197532950" target="_blank">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.
--

Mark Spring
Information Systems Manager

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

Phone: 1-888-NKTELCO
Fax: <a href="tel:(419)%20753-2950" value="+14197532950" target="_blank">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.

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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Simon Hobson

Re: Script to run on DHCPNAK

Bob Harold <[hidden email]> wrote:

> - log to syslog, and see if syslog can trigger on a string, or if it can write logs without long buffering.

The default for many syslog setups is to buffer logging - especially with DHCP it makes a big difference to disk load and generally the advice is set syslog to buffered (async) mode for the logs with DHCP traffic in them.
I wonder if this could be the "long delays" that Mark is seeing with his Bash script ?

But this does seem like a broken client. It looks like it's not processing all options when it is forced to change IP address.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

perl-list

Re: Script to run on DHCPNAK

In reply to this post by Mark Spring

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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

Phone: 1-888-NKTELCO
Fax: <a href="tel:(419)%20753-2950" target="_blank">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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Mark Spring

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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

Phone: 1-888-NKTELCO
Fax: <a href="tel:(419)%20753-2950" target="_blank">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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

perl-list

Re: Script to run on DHCPNAK

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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

Phone: 1-888-NKTELCO
Fax: <a href="tel:(419)%20753-2950" target="_blank">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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Mark Spring

Re: Script to run on DHCPNAK

Correct on the first paragraph.

Not according to cable labs, it's considered a troubleshooting interface. I asked if there was a way to make the config sticky or set an expiration. No dice :s

On Thu, Jul 20, 2017 at 2:35 PM perl-list <[hidden email]> wrote:

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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

Phone: 1-888-NKTELCO
Fax: <a href="tel:(419)%20753-2950" target="_blank">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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

perl-list

Re: Script to run on DHCPNAK

I can be of no help then. I wish you luck!

From: "Mark Spring" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
Sent: Thursday, July 20, 2017 2:37:26 PM
Subject: Re: Script to run on DHCPNAK

Correct on the first paragraph.

Not according to cable labs, it's considered a troubleshooting interface. I asked if there was a way to make the config sticky or set an expiration. No dice :s

On Thu, Jul 20, 2017 at 2:35 PM perl-list <[hidden email]> wrote:
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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: 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 <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

Phone: 1-888-NKTELCO
Fax: <a href="tel:(419)%20753-2950" target="_blank">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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Bill Shirley-2

Re: Script to run on DHCPNAK

In reply to this post by Mark Spring

You might look into Simple Event Correlator (SEC) https://simple-evcorr.github.io/

It can monitor your log files and trigger events. It's an rpm on Fedora; don't know about
other distros. There's a mailling list and Risto, the author, is always responsive.

Bill

On 7/19/2017 8:18 PM, Mark Spring wrote:

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.

I wrote a script to try and tail the log file with bash and I have been able to pick off the traffic but the buffer when tailing in bash leaves me with a case where time before the device is handled is indefinite.

I have read about the "on commit" in the config and that doesn't seem to help, the expiry and other options don't seem to fit my needs either.

I'm not necessarily committed to BASH, it just seemed to be the quickest go to without a lot of fluff...considered PERL PHP or Python. Don't have a lot of experience with one particular language, just use what works for each scenario.

Let me know where I can fill in blanks!

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Mark Spring

Re: Script to run on DHCPNAK

Bill,

I will check that out, looks like it could be handy.

My solution for the time being is to send all syslog messages to a solarwinds server. That server looks for NAK's and checks for the OUI of the gear I'm using and passes it off to another script to sleep and process the reboot command. Then solarwinds discards all messages from the DHCP server. I will be looking for a server that I can setup standalone as I don't care for solarwinds much and certainly don't like the fact that it runs on windows, but it does seem to be a good logging server and there aren't any licensing fees attached to that(since we already have the Orion software). Splunk would be a great option if they weren't also so proud about their software.

Thanks for all the input for those that chimed in!

Mark Spring

Information Systems Manager

On Fri, Jul 21, 2017 at 3:14 AM, Bill Shirley <[hidden email]> wrote:

You might look into Simple Event Correlator (SEC) https://simple-evcorr.github.io/

It can monitor your log files and trigger events. It's an rpm on Fedora; don't know about
other distros. There's a mailling list and Risto, the author, is always responsive.

Bill

On 7/19/2017 8:18 PM, Mark Spring wrote:
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.

I wrote a script to try and tail the log file with bash and I have been able to pick off the traffic but the buffer when tailing in bash leaves me with a case where time before the device is handled is indefinite.

I have read about the "on commit" in the config and that doesn't seem to help, the expiry and other options don't seem to fit my needs either.

I'm not necessarily committed to BASH, it just seemed to be the quickest go to without a lot of fluff...considered PERL PHP or Python. Don't have a lot of experience with one particular language, just use what works for each scenario.

Let me know where I can fill in blanks!

Mark Spring

Information Systems Manager

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

Phone: 1-888-NKTELCO

Fax: <a href="tel:(419)%20753-2950" value="+14197532950" target="_blank">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 [hidden email] https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users