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

Bugs item #3008084, was opened at 2010-05-27 10:43
Message generated for change (Comment added) made by infotek411
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3008084&group_id=29880

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 192.168.0.16
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 192.168.0.16 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: Jason Ellison (infotek411)
Date: 2012-03-13 17:00

Message:
I think I fixed your problem.  

check_dhcp.c incorrectly setting source ip address as siaddr - ID: 3503921

https://sourceforge.net/tracker/?func=detail&aid=3503921&group_id=29880&atid=397597#

----------------------------------------------------------------------

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

Message:
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
(http://www.symantec.com/business/support/index?page=content&id=TECH40756).
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
Wireshark.

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: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3008084&group_id=2988

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________________
Nagios Plugin Development Mailing List Nagiosplug-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null