Nagios Support Forum

Hello,

I know this has been discussed in several threads already, but having tried the suggestions in each of those already to no avail I am posting this.

Running the latest Nagios Core 3.5.0 and Plugins 1.4.16 on linux monitoring a [very functional!] linux-based ISC dhcp server in the same vlan. Monitoring *had* been working (for the last several months), but suddenly one day last week dhcp went critical. The dhcp server is working fine (or my phone would be ringing off the hook), and I'm not sure why this started happening. Restarted the dhcp server, restarted nagios, still happening. Ran wireshark on the nagios box, then the check_dhcp command manually, and I see the reply from the dhcp server landing on the nagios box in the form of a DHCP Offer but check_dhcp still fails ("CRITICAL: No DHCPOFFERs were received."). I've turned off iptables on the nagios box, so it's not a firewall issue (if it was I doubt wireshark would've seen the reply packet). I've tried various forms of the check_dhcp command, and running it as root too. Any ideas?

/usr/local/nagios/libexec/check_dhcp
/usr/local/nagios/libexec/check_dhcp -s x.x.x.x (using ip address of dhcp server)
/usr/local/nagios/libexec/check_dhcp -v
/usr/local/nagios/libexec/check_dhcp -v -s x.x.x.x (using ip address of dhcp server)
/usr/local/nagios/libexec/check_dhcp -i eth0
etc etc
I get "CRITICAL: No DHCPOFFERs were received." every time, though wireshark confirms the packet was received on the nagios box.

Thanks for any help!
-Tim

UDP port 67 is used on the server site; UDP port 68 is used on the client site. Make sure these two ports are open. Hope this helps.

lmiltchev wrote:UDP port 67 is used on the server site; UDP port 68 is used on the client site. Make sure these two ports are open. Hope this helps.

It didn't, but thank you for your quick reply
As I said, servers are on the same network, firewalls are off so ports are open, DHCP Offer packet is getting delivered as witnessed by wireshark, but yet check_dhcp fails.

The only way this "should" come up is if no valid dhcp offers were recieved. If the plug saw any offers come in, it would at the very least report that they are not valid for the expected results. Could you please return the output from "iptables -L -n" also are you running this as root or another user?

running as root
thx

# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
#

sreinhardt wrote:The only way this "should" come up is if no valid dhcp offers were recieved. If the plug saw any offers come in, it would at the very least report that they are not valid for the expected results. Could you please return the output from "iptables -L -n" also are you running this as root or another user?

Let's try specifying a different mac on your network and the correct expected IP and see what happens.
Please return all output of the command.

(command omitted, but I ran it with my desktop computer's mac address and my fixed ip address, which are in the same vlan as the dhcp and nagios servers, as they are listed in the dhcpd.conf file)

DHCP socket: 3
DHCPDISCOVER to 255.255.255.255 port 67
DHCPDISCOVER XID: 617080213 (0x24C7E595)
DHCDISCOVER ciaddr: 0.0.0.0
DHCDISCOVER yiaddr: 0.0.0.0
DHCDISCOVER siaddr: 0.0.0.0
DHCDISCOVER giaddr: 0.0.0.0
send_dhcp_packet result: 548




No (more) data received (nfound: 0)
Result=ERROR
Total responses seen on the wire: 0
Valid responses for this machine: 0
CRITICAL: No DHCPOFFERs were received.


Thx again

sreinhardt wrote:Let's try specifying a different mac on your network and the correct expected IP and see what happens.

Code: Select all

check_dhcp -m [some other mac] -r [IP for some other mac] -t 60 -i eth0 -v

Please return all output of the command.

Figured it out, and of course I caused it. Here's what happened: We have two servers setup for dhcp, but of course it's only running on one of them (the dhcpd.conf file gets copied from primary to standby every couple of minutes). Yes we have to manually flip it over, but just forget about that for now. So a few months back we manually flipped it over to do some maintenance on the primary server, and I edited the dhcpd.conf file to change the server-identifier field to that of the standby server. When I moved it back, I never changed it back. Well it functioned and didn't complain, but I noticed it the other day and changed it. Problem is I changed it to the name of the primary server (not its IP), and that name was listed in its /etc/hosts file on the same line as 127.0.0.1 localhost ... so the dhcp reply packet came from 127.0.0.1 instead of the expected ip address of the dhcp server, which is probably why check_dhcp failed (as it should've).

Anyway, thought you'd want to know

We're happy now, the service shows green in nagios now (and there was much rejoicing... yayyyy...).

Thx
T

Ha, thanks for letting us know. I noticed that in the PM, and was going to comment\do some testing internally and see if I got the same result. Glad its working!