[Nagiosplug-devel] [ nagiosplug-Bugs-3008084 ] check_dhcp Microsoft Server Options 66 and 67 CRITICAL

SourceForge.net noreply at sourceforge.net
Fri Feb 17 02:50:38 CET 2012

Bugs item #3008084, was opened at 2010-05-27 10:43
Message generated for change (Comment added) made by martinkonrad
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General plugin execution
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: arch nemesis (mstng67)
Assigned to: Nobody/Anonymous (nobody)
Summary: check_dhcp Microsoft Server Options 66 and 67 CRITICAL

Initial Comment:
Plugin Version (-V output): check_dhcp v1.4.14 (nagios-plugins 1.4.14)
Plugin Name: check_dhcp
Plugin Commandline showing issues: /usr/lib/nagios/plugins/check_dhcp -s
Output from above command: CRITICAL: Received 1 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 0 sec.
Operating System: Linux Mint 8 Helena - Main Edition
Architecture: x86
Compiler: ??? The plugins were installed using APT.
The change that prompted the CRITICAL output: Added Microsoft DHCP server options 66 and 67 to DHCP server configuration. These options are Boot Server Host Name and Bootfile Name, respectively. Restart the DHCP service. The next check of the DHCP server yielded the above output.
Number of DHCP servers on the network: 1. The above mentioned MS DHCP server is the only DHCP server on the network.

My guess is that the plugin is incorrectly parsing the options returned in the DHCPOFFER. I have no proof to back up this theory except that if the DHCP server is re-configured back to the known good (without options 66 and 67) then the plugin returns OK. If options 66 and 67 are configured the plugin returns CRITICAL for the specified server.

Until a fix is released, I have simply removed the -s portion of the command config file for the dhcp plugin to ensure that the plugin responds OK as long as it receives a DHCPOFFER. I know that it's a temporary fix, but it's what I know to do for now. If you need additional information, please email me.


Comment By: Martin Konrad (martinkonrad)
Date: 2012-02-16 17:50

I can confirm the described behavior. But as it seems there is no fix:
Microsoft delivers the data from the DHCP option 66 field as "next server
ip address" to work around some buggy PXE devices
That's why check_dhcp thinks the DHCP server is behind a DHCP proxy which
of course is not the case. I confirmed that looking at the DHCP offer with

There are two ways around that:
1. Do not check the IP of the DHCP server.
2. Check against your TFTP boot-server's IP.

Hope that helps...


You can respond by visiting: 

More information about the Devel mailing list