check snmp problem and cant find the reason

jgking at packetstorm.org jgking at packetstorm.org
Fri Jan 24 17:04:32 CET 2003


ok this is getting on the wierd side. After finding out that plugin 
versions were different on the systems, I updated the production box and 
still had the same error even though the -v switch does work now.

So i wanted to really be sure the code was the same so i compared 
md5 checksums on both tarballs. Both match.

I then look at the check_snmp.c and check_snmp.o files and got this

-rwxr-xr-x    1 root     root        93038 Jan 21 07:35 check_snmp
-rw-r--r--    1 5313     5313        26494 Nov 15 23:06 check_snmp.c
-rw-r--r--    1 root     root        58648 Jan 21 07:35 check_snmp.o


-rwxr-xr-x    1 root     root        90143 Jan 24 07:07 check_snmp
-rw-r--r--    1 5313     5313        26494 Nov 15 23:06 check_snmp.c
-rw-r--r--    1 root     root        63092 Jan 24 07:07 check_snmp.o

So i ran a diff on the check_snmp.c file and it all compares fine. As for 
the other 2 binary files, they dont matchup.

There is a hardware difference (first is a single processor and the second 
is from the production dual processor) and Im going to start looking at 
the rpm 
versions for the RedHat base to see what could be causing the filesize 
diff on the compiled results. 

To save me some time though, anyone know offhand if the hardware 
differences would result in the larger binaries? BTW the production box 
is still "in-dev" and not plugged into a public network and no tripwire 
alerts have been flagged

>From testing check_snmp the "hang" issue gets fixed if i remove the -d 
option. Heres a before and after


[ nagios]$ libexec/check_snmp -v -H localhost -o 
.1.3.6.1.4.1.2021.10.1.101.1,.1.3.6.1.4.1.2021.10.1.101.2,.1.3.6.1.4.1.2021.10.1.101.3 
-s "" -d "STRING: " -C *******
/usr/bin/snmpget -m ALL -v 1 -c ***** localhost:161  
.1.3.6.1.4.1.2021.10.1.101.1 .1.3.6.1.4.1.2021.10.1.101.2 
.1.3.6.1.4.1.2021.10.1.101.3
enterprises.ucdavis.laTable.laEntry.laErrMessage.1 = 
enterprises.ucdavis.laTable.laEntry.laErrMessage.2 = 
enterprises.ucdavis.laTable.laEntry.laErrMessage.3 = 

SNMP problem - No data recieved from host
CMD: /usr/bin/snmpget -m ALL -v 1 -c ****** localhost:161  
.1.3.6.1.4.1.2021.10.1.101.1 .1.3.6.1.4.1.2021.10.1.101.2 
.1.3.6.1.4.1.2021.10.1.101.3

remove the switch and voila!

libexec/check_snmp -v -H localhost -o 
.1.3.6.1.4.1.2021.10.1.101.1,.1.3.6.1.4.1.2021.10.1.101.2,.1.3.6.1.4.1.2021.10.1.101.3 
-s ""  -C *****
/usr/bin/snmpget -m ALL -v 1 -c ***** localhost:161  
.1.3.6.1.4.1.2021.10.1.101.1 .1.3.6.1.4.1.2021.10.1.101.2 
.1.3.6.1.4.1.2021.10.1.101.3
enterprises.ucdavis.laTable.laEntry.laErrMessage.1 = 
enterprises.ucdavis.laTable.laEntry.laErrMessage.2 = 
enterprises.ucdavis.laTable.laEntry.laErrMessage.3 = 

SNMP OK - 



Anyhow, im gonna start looking at possible rpm variances now :)


-Greg

On Thu, 23 Jan 2003, Subhendu Ghosh wrote:

> 
> Can you try running the plugin with a "-v" option (verbose mode - not 
> documented) - it prints the command and the output of the command.
> 
> -sg
> 
> 
> On Thu, 23 Jan 2003, Kelly Setzer wrote:
> 
> > > From: jgking at packetstorm.org
> > > 
> > > Ok i have 2 linux systems, one i test on and the other is where i deploy 
> > > after testing. On the test system everything works just fine. On the 
> > > production system nagios cannot get a return value from the snmp daemon.
> > > 
> > > 5. So as the nagios id i then run the libexec/check_snmp program passing 
> > > it the above information. It works as well
> > > 
> > > So what could be causing the nagios client to not be able to connect to 
> > > the snmpdaemon?
> > > 
> > > All im getting back on this box is "SNMP problem - No data recieved from 
> > > host "
> > 
> > I am having the same problem - intermittently.  I recently added SNMP
> > monitoring to a completely functional nagios installation.  I have
> > about 80 services that use check_snmp.  On two hosts, I see recurring
> > errors as above, "No data received from host".  We have 156 services
> > total that we are monitoring.
> > 
> > I've done extensive testing to prove to me that snmpget on the nagios
> > server functions correctly.  I also did some load testing against the
> > two problem hosts and was NEVER able to get snmpget to fail.
> > 
> > However, by putting a shell-script wrapper around snmpget and using that
> > to log all calls from check_snmp, I am seeing cases where check_snmp
> > *apparently* doesn't get any data back from snmpget.  I believe this
> > is an issue with check_snmp.
> > 
> > I have tried several versions of the net-snmp/ucd-snmp package on
> > both the nagios server and the affected hosts.  That had no effect.
> > I have tried both 1.3.0b2 and 1.3b1 of the nagios-plugins.  Persistently
> > "re-scheduling service checks" will cause this problem to disappear,
> > sometimes for several days at a stretch.
> > 
> > Kelly
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Nagios-users mailing list
> > Nagios-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > 
> 
> 



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com




More information about the Users mailing list