snmptt not translating these traps. Any thoughts?

[drsprite]

I have a device that is sending snmp v1 traps and snmptt isn't translating them correctly.

For troubleshooting, I stopped the snmptt service, and copied the trap from snmptrapd to /tmp.

Here's the raw trap from snmptrapd that was placed into /var/spool/snmptt. The OID I'm trying to trigger off of is: .1.3.6.1.4.1.476.1.42.3.2.1.15

Code: Select all

<UNKNOWN>
UDP: [10.108.64.250]:4999->[170.6.78.54]
.1.3.6.1.2.1.1.3.0 1:7:58:27.81
.1.3.6.1.6.3.1.1.4.1.0 .1.3.6.1.4.1.476.1.42.3.3.0.0.2
.1.3.6.1.4.1.476.1.42.3.2.3.1.1.19 19
.1.3.6.1.4.1.476.1.42.3.2.3.1.2.19 .1.3.6.1.4.1.476.1.42.3.2.1.15
.1.3.6.1.4.1.476.1.42.3.2.3.1.3.19 1:7:58:27.79
.1.3.6.1.6.3.18.1.3.0 10.108.64.250
.1.3.6.1.6.3.18.1.4.0 "public"
.1.3.6.1.6.3.1.1.4.3.0 .1.3.6.1.4.1.476.1.42.3.3.0

Here's the entry from snmpttunknown.log:

Code: Select all

Thu Jul 10 14:32:05 2014: Unknown trap (.1.3.6.1.4.1.476.1.42.3.3.0.0.2) received from 10.108.64.250 at: 
Value 0: 10.108.64.250
Value 1: 10.108.64.250
Value 2: 1:5:34:06.89
Value 3: .1.3.6.1.4.1.476.1.42.3.3.0.0.2
Value 4: 10.108.64.250
Value 5: public
Value 6: .1.3.6.1.4.1.476.1.42.3.3.0
Value 7: 
Value 8: 
Value 9: 
Value 10: 
Ent Value 0: .1.3.6.1.4.1.476.1.42.3.2.3.1.1.15=15
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.2.3.1.2.15=.1.3.6.1.4.1.476.1.42.3.2.1.1
Ent Value 2: .1.3.6.1.4.1.476.1.42.3.2.3.1.3.15=1:4:57:29.29

As you can see, snmptt thinks the OID is .1.3.6.1.4.1.476.1.42.3.3.0.0.2.

I know snmptt can do wildcard matching, but that's based off the OID it thinks it is (the wrong .1.3.6.1.4.1.476.1.42.3.3.0.0.2 in this example). That won't work for me since a few different traps are coming in as the same wrong OID.

Is there maybe a way to have snmptt trigger off a wildcard from INSIDE the trap that snmptrapd places into the spool folder?

I doubt the vendor will do a firmware update for this, so I think I'm kinda on my own.

[sreinhardt]

I doubt the vendor will do a firmware update for this, so I think I'm kinda on my own.

I think you hit the nail on the head here, this isn't really snmptt not recognizing your oid as much as your vendor mib and trap sent from the device are not matching up.

To answer your other questions. It is definitely better to take the oid that your device is sending (.1.3.6.1.4.1.476.1.42.3.3.0.0.2) and replace the trap oid configuration in snmptt.conf (.1.3.6.1.4.1.476.1.42.3.2.1.15) format line with the "correct" oid, opposed to doing wildcard matching. Also I do not know of a way to match anything other than the sending oid, I don't think it is presently possible to configure snmptt to match internal trap oids to overall oids.

[drsprite]

To answer your other questions. It is definitely better to take the oid that your device is sending (.1.3.6.1.4.1.476.1.42.3.3.0.0.2) and replace the trap oid configuration in snmptt.conf

I was afraid of that. The OID it's reporting is the "Notification" OID. So I guess I could just trap to Nagios with a generic "There is a problem with this device" notification, and leave it up to the tech to log in and view the proper alert.

I sent an email to the vendor, but I think it's a catchall account - so it may be a black hole.