check_snmp problem "No data received from host"


Sorry for write out of the mailing list, but I stuck with problem

I have the following error message in nagios logs:

[1210863277] SERVICE ALERT: sw1;Uptime;UNKNOWN;SOFT;1;SNMP problem -
No data received from host
[1210863337] SERVICE ALERT: sw1;Uptime;UNKNOWN;SOFT;2;SNMP problem -
No data received from host
[1210863397] SERVICE ALERT: sw1;Uptime;UNKNOWN;SOFT;3;SNMP problem -
No data received from host
[1210863457] SERVICE ALERT: sw1;Uptime;UNKNOWN;HARD;4;SNMP problem -
No data received from host

If I run plugin directly on a shell, I get:

/usr/lib64/nagios/plugins/check_snmp -H -o .
-C “somestring” -n -P 2c
SNMP problem - No data received from host
CMD: /usr/bin/snmpgetnext -t 1 -r 5 -m ‘’ -v 2c [authpriv] .

Please, give a hint, I don’t know what to do, it the plugin broken?

I am using nagios-plugins-1.4.11-1.el5.rf and nagios-2.11-1.el5.rf


I am not sure if I can be of some help here… I will give it a shot. Have you made sure that you have the check command configured in the nrpe.conf on the remote server? That might be part of your problem…


Have you checked if your Nagios server is authorised by the host. On some of the hosts in my setup I had to specify the adress of my Nagios server to be able to get SNMP replies, and some hosts were set up to only allow the old monitoring server, so my new server did not get any replies.

Hope this helps you :wink:



i’m having a similar problem as sebelk, being that when running the ./check_snmp, i get the reply no data received from Host. I’m queyring a sonicwall firewall and snmp is enabled on that end, with the nagios server being specified as allowed to query the snmp info from the firewall.

here is what i run on the command line:
nagios:/usr/local/nagios/libexec# ./check_snmp -H -o . -C "public"
SNMP problem - No data received from host
CMD: /usr/bin/snmpget -t 1 -r 5 -m ‘’ -v 1 [authpriv] .

anybody got any ideas how to resolve this?



when you try to run the check_snmp in command line and the error message appears, you should also see the command that check_snmp tried to run.

Taking sebelk example:
/usr/lib64/nagios/plugins/check_snmp -H -o .
-C “somestring” -n -P 2c
SNMP problem - No data received from host
CMD: /usr/bin/snmpgetnext -t 1 -r 5 -m ‘’ -v 2c [authpriv] .

copy and paste this command to run it.
=> sometimes, the error message is more explicit (sadely, it’s quite rare :)).

With some luck, you’ve already found the problem.

Assuming that it doesn’t work better (ie: the command you pasted exists with an error), there is one thing you can do:
log in on the firewall you want to poll, and see the logs: does it receives the snmp request ?
does it answer it ?
and if yes: through which route ? (btw: I’ve had many times the problem with the route to answer that was not defined, so the firewall just throes the reply to the default route…).

hope this helps a little bit :slight_smile:


Hi Loose,

thanks for the answer, i tried running the snmpget command, but when i do so, i get the following output:
nagios:/usr/local/nagios/libexec# /usr/bin/snmpget -t 1 -r 5 -m ‘’ snmpget: Timeout

i checked the firewall logs and this is what i found, running the check_snmp on the same subnet as the nagios is on:
Notice Network Access UDP packet from LAN dropped, 3420, ESX, 161, ESX IP Protocol: 0 Port: 0

that would point to a problem on the firewall i pressume? although the nagios server should have full access


Sorry, I can’t help you further, as I don’t know much about firewalls :frowning:

but as the packet is dropped, it means that you have a problem on the firewall (wrong community ? wrong SNMP version ? not enough rights … etc)

good luck :wink:


As further searching showed, it looks like there is still an issue with the check_snmp on debian on my system, since getting snmp info from an hp printer gives the same error. however when i run a snmptester on my windows client, that gives me the snmp info from the printer …so searching in both directions for the firewall & check_snmp on the linux box …

thanks for your help though