SNMP Traps Not Trapping

Greetings. I am new to the product and in evaluation period.

I have configured serverscheck to monitor SNMPTRAP, but it appears to be not working. Here is my configuration of the trap.



Allowed IP Range: *.*.*.*

community: public

Generic ID : All

OID: *

OID Type: text

OID value: ignore value

When trap matches...: DOWN



I also created another rule with OID Type: integer



ServersCheck is running on Win2003 Server.

SNMP Service is running.

SNMP Trap Service is running.

netstat -na shows snmptrap.exe listening on port 162.



I know that traps are indeed being sent to this host as I momentarily stopped all services and ran a different SNMPTrapper, and it reported the traps. I then re-enabled the SNMP services.



When I send traps to ServersCheck host, I see no indication of them being received or processed.

The SNMP Trap service may not be running. This is a different service that has nothing to do with our product.



ServersCheck comes with its own SNMP Trap listener: monitoring_snmptrap.exe



After you defined it, restart the ServersCheck Monitoring service



In your process list (task manager) you should see the monitoring_snmptrap.exe running and a netstat -na should provide the same result.

I have now stopped the 'SNMP Trap Service', and disabled it.

I then restarted ServersCheck Monitoring Service.

I can confirm that UDP port 162 is now owned by monitoring_snmptrap.exe*32.



I still cannot see any indication that the trap was received or processed. I am looking at the Dashboard - All Rules View.



What next?

You can view the activity of the snmp trap receiver by running it in debug mode (similar for all components):



1/ kill the monitoring_snmptrap.exe process

2/ open command window

3/ go to main serverscheck directory

4/ in there type following command

monitoring_snmptrap.exe > debuglog.txt



It takes a minute to initialize, after that fire some traps and press CTRL+C to stop the process. Open the debuglog.txt file and in there you will see the traps that have been received



Ensure that there is no local firewall blocking incoming UDP messages.

Very helpful.

I see this message as soon as I send the trap:



Thread 1 terminated abnormally: Bad arg length for Socket::inet_ntoa, length is

0, should be 4 at monitoring_snmptrap.pl line 1259.



After which there is no more visible logging from the application, regardless of how many traps are sent. I repeated this test several times.



Maybe the sending application has a poorly formed SNMP message? I will generate a wireshark trace. Do you want me to send it somewhere?

I will try to reach a developer to see if something quick can be done on it.



Hold on for 30 minutes

Please download an updated version of the monitoring_snmptrap.exe from following url. Replace current with downloaded and then try again in debug mode.



http://files.serverscheck.net/fixes/monitoring_snmptrap.zip



UPDATE:

It will still fail but at least it will show some debugging info just before failing allowing us to have some more data. It might be related to the fact that the sender data in the SNMP is not correct.

Here is what is seen in log:

# Mon Oct 29 17:17:12 2007 trap received from - - 1.3.6.1.2.1.1.3.0|151970572|

|1.3.6.1.6.3.1.1.4.1.0|1.3.6.1.4.1.8008.2.2.5||1.3.6.1.4.1.8008.2.2.5|test test

test||

Thread 1 terminated abnormally: Bad arg length for Socket::inet_ntoa, length is

0, should be 4 at monitoring_snmptrap.pl line 1261.

# Mon Oct 29 17:17:13 2007 trap ignored for 1193682700SNMPTRAP; no match for com

munity and public

# Mon Oct 29 17:17:13 2007 trap ignored for 1193683655SNMPTRAP; no match for com

munity and public

# Mon Oct 29 17:17:13 2007 trap 0 removed - match result: 0

OK the problem is that it does have a senders address but it seems no longer to block there.



In your settings remove the community: Public (so make it empty).



Repeat above and then it should have a match resulting in an alert.

The Editor Monitor Rule page won't allow an empty Community String.

Here is a trick to bypass it:



1/ open the serverscheck.conf file in the /conf subdirectory with notepad

2/ find the line starting with SNMPTRAP and in there remove the public value

I removed public from the .conf file.

I restarted only monitoring_snmptrap.exe.

I sent the same trap, and got the what looks like the same error, but with one more useful log line (maybe I didn't see it earlier):



# Mon Oct 29 18:17:19 2007 trap received from - - 1.3.6.1.2.1.1.3.0|152331222|

|1.3.6.1.6.3.1.1.4.1.0|1.3.6.1.4.1.8008.2.2.5||1.3.6.1.4.1.8008.2.2.5|test test

test||

Thread 1 terminated abnormally: Bad arg length for Socket::inet_ntoa, length is

0, should be 4 at monitoring_snmptrap.pl line 1261.

We have modified the code for that component to handle empty IP address values in SNMP Traps



Try again with this update:

http://files.serverscheck.net/fixes/monitoring_snmptrap.zip

Unfortunately, the zip file referenced by that url contains the same binary. I ran sum.exe to compare and they are the same.

Also, to avoid browser cache, I tired downloading from a different (fresh) PC and got the same results.



Was there a typo?

We have uploaded a new executable. Please try again.

http://files.serverscheck.net/fixes/monitoring_snmptrap.zip

I downloaded the new executable (sum result is 34534 1289).

I ran it in console.

It handled one trap, and then no more after that.

Here is the output from the console.



# Thu Nov 1 15:22:14 2007 trap received from - - 1.3.6.1.2.1.1.3.0|177199965|

|1.3.6.1.6.3.1.1.4.1.0|1.3.6.1.4.1.8008.2.2.5||1.3.6.1.4.1.8008.2.2.5|test test

test||

Thread 1 terminated abnormally: Bad arg length for Socket::inet_ntoa, length is

0, should be 4 at monitoring_snmptrap.pl line 1261.

# Thu Nov 1 15:22:15 2007 trap / oid ignored for 1193682700SNMPTRAP; no match f

or oid id 1.3.6.1.2.1.1.3.0 and

# Thu Nov 1 15:22:15 2007 trap / oid ignored for 1193682700SNMPTRAP; no match f

or oid id 1.3.6.1.6.3.1.1.4.1.0 and

# Thu Nov 1 15:22:15 2007 trap / oid ignored for 1193682700SNMPTRAP; no match f

or oid id 1.3.6.1.4.1.8008.2.2.5 and

# Thu Nov 1 15:22:15 2007 trap / oid ignored for 1193683655SNMPTRAP; no match f

or oid id 1.3.6.1.2.1.1.3.0 and

# Thu Nov 1 15:22:15 2007 trap / oid ignored for 1193683655SNMPTRAP; no match f

or oid id 1.3.6.1.6.3.1.1.4.1.0 and

# Thu Nov 1 15:22:15 2007 trap / oid ignored for 1193683655SNMPTRAP; no match f

or oid id 1.3.6.1.4.1.8008.2.2.5 and

# Thu Nov 1 15:22:15 2007 trap 0 removed - match result: 0

Plz ignore previous post!



On closer inspection the browser downloaded an old version of the zip. I have downloaded a fresh copy of the zip file and i'm evaluating it now.

The current version of monitoring_snmptrap.exe now at least does NOT die when receiving the 'trap of death'. It gives the output, below.



I am currently running both monitoring_manager and monitoring_snmptrap now as console apps.



Why do I not trigger any of the rules (described early in the thread, above) ? I thought that I had configured the rule to go DOWN on any value for text or numeric.



Output:



# Thu Nov 1 15:39:30 2007 trap received from 0.0.0.0 - - 1.3.6.1.2.1.1.3.0|177303560||1.3.6.1.6.3.1.1.4.1.0|1.3.6.1.4.

1.8008.2.2.5||1.3.6.1.4.1.8008.2.2.5|test test test||

# Thu Nov 1 15:39:31 2007 trap / oid ignored for 1193682700SNMPTRAP; no match for oid id 1.3.6.1.2.1.1.3.0 and

# Thu Nov 1 15:39:31 2007 trap / oid ignored for 1193682700SNMPTRAP; no match for oid id 1.3.6.1.6.3.1.1.4.1.0 and

# Thu Nov 1 15:39:31 2007 trap / oid ignored for 1193682700SNMPTRAP; no match for oid id 1.3.6.1.4.1.8008.2.2.5 and

# Thu Nov 1 15:39:31 2007 trap / oid ignored for 1193683655SNMPTRAP; no match for oid id 1.3.6.1.2.1.1.3.0 and

# Thu Nov 1 15:39:31 2007 trap / oid ignored for 1193683655SNMPTRAP; no match for oid id 1.3.6.1.6.3.1.1.4.1.0 and

# Thu Nov 1 15:39:31 2007 trap / oid ignored for 1193683655SNMPTRAP; no match for oid id 1.3.6.1.4.1.8008.2.2.5 and

# Thu Nov 1 15:39:31 2007 trap 3 removed - match result: 0

The wildcard seemed to cause an issue on the trap matching.



This has been solved.



You can download it from following url:

http://files.serverscheck.net/fixes/monitoring_snmptrap.zip