snmpv3 traps - snmptt unable to find a match in MIB

[Dipu]

Hi,

An snmpv3 'coldStart' trap is sent from a remote machine to Nagios monitoring server. The snmptt debug file says that a match for this trap is not available in the MIB though the MIB has an entry for coldStart. Hence the trap is not captured by Nagios TRAP service. But, if we execute the snmptt.conf file's EXEC command(based on submit_check_result plugin) directly from command line, the same gets updated in Nagios TRAP service panel.

snmptt.conf entry for coldStart
--------------------------------------------
EVENT coldStart .1.3.6.1.6.3.1.1.5.1 "Status Events" Normal
FORMAT A coldStart trap signifies that the SNMP entity, $*
EXEC /usr/local/nagios/libexec/eventhandlers/submit_check_result localhost TRAP 3 "test2"
SDESC
A coldStart trap signifies that the SNMP entity,
supporting a notification originator application, is
reinitializing itself and that its configuration may
have been altered.
Variables:
EDESC

MIB entry for coldStart from @ /usr/local/share/snmp/mibs
-----------------------------------------------------------------------------------
coldStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"A coldStart trap signifies that the SNMP entity,
supporting a notification originator application, is
reinitializing itself and that its configuration may
have been altered."
::= { snmpTraps 1 }

snmpv3 trap format
--------------------------
snmptrap -e 0x0102030405 -v 3 -u testuser -a MD5 -A testuser123 -l authNoPriv 192.168.1.35 42 coldStart.0 (we tried with OID as well, instead of 'coldStart')

Excerpt from snmptt.debug file
-------------------------------------------
Exact match of trap NOT found in EVENT hash table

Looking for wildcards in the EVENT hash table
Drilling down looking for wildcards in the EVENT hash table
SNMPv2-MIB::coldStart.*

Drilling down looking for wildcards in the EVENT hash table
SNMPv2-MIB::coldStart.*

Drilling down looking for wildcards in the EVENT hash table
SNMPv2-MIB::coldStart.*

Drilling down looking for wildcards in the EVENT hash table
SNMPv2-MIB::coldStart.*

Drilling down looking for wildcards in the EVENT hash table
SNMPv2-MIB::coldStart.*

This causes traps to be logged as UNKNOWN in NSTI as well. Please help us in fixing the issue.

[sreinhardt]

Can you provide us with the oid that your test actually sends instead of the shortname? Most of the time, snmp v1, v2, and v3 traps while sharing same or similar names, have different oid's and will not be interpreted correctly unless they have been added. In this case, I believe you are expecting the snmpv2 coldstart oid to match the snmpv3 same shortname, which might not be the same oid.

[rajesh_chanda]

Hi myself and the one posted this query work together . So I am giving more details on the same.

snmptranslate -On SNMPv2-MIB::coldStart.0
.1.3.6.1.6.3.1.1.5.1.0

[root@pqmsweb mibs]# snmptranslate -On SNMPv2-MIB::coldStart
.1.3.6.1.6.3.1.1.5.1


We tried with snmpV2c and snmpV1 traps as well.

here are the traps that we tried.

snmptrap -v2c -c public 192.168.1.35:162 "" .1.3.6.1.6.3.1.1.5.1 coldStart s "Start"


portion of snmpttunkonwnlog for the above trap is as follows.

tail -f /var/log/snmptt/snmpttunknown.log
Wed Mar 5 22:19:29 2014: Unknown trap (SNMPv2-MIB::coldStart) received from pqmsweb at:
Value 0: pqmsweb
Value 1: 192.168.1.35
Value 2: 57:22:06:38.48
Value 3: SNMPv2-MIB::coldStart
Value 4: 192.168.1.35
Value 5:
Value 6:
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: SNMPv2-MIB::coldStart=Start
For Trap snmptrap -v2c -c public 192.168.1.35:162 "" .1.3.6.1.6.3.1.1.5.1.0 coldStart s "Start"

Wed Mar 5 22:21:32 2014: Unknown trap (SNMPv2-MIB::coldStart.0) received from pqmsweb at:
Value 0: pqmsweb
Value 1: 192.168.1.35
Value 2: 57:22:08:40.97
Value 3: SNMPv2-MIB::coldStart.0
Value 4: 192.168.1.35
Value 5:
Value 6:
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: SNMPv2-MIB::coldStart=Start.

portion ofsnmptt.ini is
[TrapFiles]
# A list of snmptt.conf files (this is NOT the snmptrapd.conf file). The COMPLETE path
# and filename. Ex: '/etc/snmp/snmptt.conf'
snmptt_conf_files = <<END
/etc/snmp/snmpttv2.conf.SNMPv2-MIB
END

portion of /etc/snmp/snmpttv2.conf.SNMPv2-MIB

EVENT coldStart .1.3.6.1.6.3.1.1.5.1 "Status Events" Normal
FORMAT A coldStart trap signifies that the SNMP entity, $*
EXEC /usr/local/nagios/libexec/eventhandlers/submit_check_result $r TRAP 1 "A coldStart trap signifies that the SNMP entity, $*"
SDESC
A coldStart trap signifies that the SNMP entity,
supporting a notification originator application, is
reinitializing itself and that its configuration may
have been altered.
Variables:
EDESC
#

Please let us know any more details are required to solve this issue.

Regards,
Dipu/Rajesh

[sreinhardt]

That is very interesting, and thank you for the additional notes. I can see where the initial coldstart one should have worked, although with the additional 0 I believe it still (sh/w)ould have failed. Let's enable debugging and send a few more to see what errors it might be having.

In /etc/snmp/snmptt.ini modify the following lines to look like these:

Code: Select all

DEBUGGING = 2

# Debugging file - SNMPTT
# Location of debugging output file.  Leave blank to default to STDOUT (good for
# standalone mode, or daemon mode without forking)
#DEBUGGING_FILE =
DEBUGGING_FILE = /var/log/snmptt/snmptt.debug

# Debugging file - SNMPTTHANDLER
# Location of debugging output file.  Leave blank to default to STDOUT
#DEBUGGING_FILE_HANDLER =
DEBUGGING_FILE_HANDLER = /var/log/snmptt/snmptthandler.debug

restart both snmptt and snmptrapd services:

Code: Select all

service snmptt restart
service snmptrapd restart

Send a few traps, then attach or paste in the debug files please.