2

I have a device that is sending snmp v1 traps and snmptt cannot translate them. To grab a copy of the trap, I stopped the snmptt service, and copied the trap to /tmp.

The OID I'm trying to trigger off of is:

.1.3.6.1.4.1.476.1.42.3.2.1.15

Here's the raw trap from /var/spool/snmptt:

<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:

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. It is not.

Is there a way to configure snmptt to trigger off any matching OID within the trap?

Any other way to save this without going to the vendor (which I am thinking is a large black hole).

dawud
  • 15,096
  • 3
  • 42
  • 61
Pat
  • 274
  • 3
  • 14
  • Oh, Liebert... if it's any consolation, I gave up when trying to process traps from our Liebert CRACs for similar reasons. Instead, we have a script that queries the active alarms, and this script is triggered any time a trap is received ;-) – Keith Jul 11 '14 at 13:45
  • @Keith is it an active check? We have an active check now, but it's not overly helpful when we have an alarm come in while the active check is sleeping. The passive traps checks were ideal, but their traps are messed up. – Pat Jul 11 '14 at 14:07
  • 1
    It's a passive check. We use the EXEC capability of snmptt to run the "query current alarms" perl script whenever a trap is received, and this script submits the actual passive check results. – Keith Jul 22 '14 at 14:10
  • Not a bad idea. Have EXEC call a perl script which could run a regexp against the whole trap to try and find the specific OIDs I care about. – Pat Jul 22 '14 at 14:21

1 Answers1

0

I was able to figure this out. Liebert indicated that they only trap on 1 OID. Then varbind 2 contains the OID specific alarm. So in SNMPTT, I created a special Liebert script that takes varbind 2 (which is $2 from the EXEC), then match it to a case statement, which sets the Nagios alert for the varbind 2 OIDs we care about.

Pat
  • 274
  • 3
  • 14