SNMPTT Problems

jameyw · Post by **jameyw** » Thu Jun 21, 2018 11:15 am

I am working on integrating SNMP Traps into my configuration. I set up a test XI server and followed the tutorial at https://support.nagios.com/kb/article/n ... al-77.html. I was able to complete the tutorial successfully. Today, I am working with one of the devices on my network. It is a Serverscheck Sensorgateway. I have confirmed that my test server is seeing traps coming from the device. I then loaded the MIB file and ticked the "Process Trap" checkbox. I then restarted the SNMPTT service. Traps from the device are still showing up in the SNMPTTUNNKOWN log. I checked the snmptt.conf file and the information from the MIB is in the file. I'm not at a point now that I'm not sure how to proceed or how to troubleshoot.

Here is the info from the MIB file:

Code: Select all

MIB: ServersCheck (file:/usr/share/snmp/mibs/sensorgateway.mib) converted on Thu Jun 21 09:27:32 2018 using snmpttconvertmib v1.3
#
#
#
EVENT sensorAlert .1.3.6.1.4.1.17095.0.1 "Status Events" Normal
FORMAT An alert has been triggered by the SensorGateway on $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "An alert has been triggered by the SensorGateway on $*"
SDESC
An alert has been triggered by the SensorGateway on
one of the connected sensors.  See the detailed error
message for information.
Variables:
  1: sensor1TrapErrMsg
  2: sensor2TrapErrMsg
  3: sensor3TrapErrMsg
  4: sensor4TrapErrMsg
  5: sensor5TrapErrMsg
  6: sensor6TrapErrMsg
EDESC
#
#
#
EVENT iosensorAlert .1.3.6.1.4.1.17095.0.2 "Status Events" Normal
FORMAT An alert has been triggered by the SensorGateway on $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "An alert has been triggered by the SensorGateway on $*"
SDESC
An alert has been triggered by the SensorGateway on
one of the connected sensors.  See the detailed error
message for information.
Variables:
  1: iosensorINPUT1trapErrMsg
  2: iosensorINPUT2trapErrMsg
  3: iosensorINPUT3trapErrMsg
  4: iosensorINPUT4trapErrMsg
  5: iosensorINPUT5trapErrMsg
  6: iosensorINPUT6trapErrMsg
  7: iosensorINPUT7trapErrMsg
  8: iosensorINPUT8trapErrMsg
  9: iosensorINPUT9trapErrMsg
  10: iosensorINPUT10trapErrMsg
  11: iosensorINPUT11trapErrMsg
  12: iosensorINPUT12trapErrMsg
  13: iosensorINPUT13trapErrMsg
  14: iosensorINPUT14trapErrMsg
  15: iosensorINPUT15trapErrMsg
  16: iosensorINPUT16trapErrMsg
EDESC

Here are two traps received from the device:

Code: Select all

Thu Jun 21 10:53:22 2018: Unknown trap (.1.3.6.1.4.1.17095.0.0) received from 10.132.10.20 at: 
Value 0: 10.132.150.20
Value 1: 10.132.10.20
Value 2: 0:1:33:46.47
Value 3: .1.3.6.1.4.1.17095.0.0
Value 4: 10.132.10.20
Value 5: public
Value 6: .1.3.6.1.4.1.17095
Value 7: 
Value 8: 
Value 9: 
Value 10: 
Ent Value 0: .1.3.6.1.4.1.17095.5.4.1.0=TEST,Triggered,Triggered,21 June 2018,09:53:22


Thu Jun 21 10:53:43 2018: Unknown trap (.1.3.6.1.4.1.17095.0.0) received from 10.91.150.20 at: 
Value 0: 10.132.10.20
Value 1: 10.132.10.20
Value 2: 0:1:34:07.74
Value 3: .1.3.6.1.4.1.17095.0.0
Value 4: 10.132.10.20
Value 5: public
Value 6: .1.3.6.1.4.1.17095
Value 7: 
Value 8: 
Value 9: 
Value 10: 
Ent Value 0: .1.3.6.1.4.1.17095.5.4.1.0=TEST,OK,Recover,21 June 2018,09:53:43

scottwilkerson · Post by **scottwilkerson** » Thu Jun 21, 2018 2:25 pm

The trap is for .1.3.6.1.4.1.17095.0.0

The entry you have is for .1.3.6.1.4.1.17095.0.1

These will not match

jameyw · Post by **jameyw** » Tue Jun 26, 2018 12:08 pm

Yes, I figured that out after I posted.

Trying to get anything useful setup is proving to be difficult. All the device sends are these:

Code: Select all

Thu Jun 21 10:53:22 2018: Unknown trap (.1.3.6.1.4.1.17095.0.0) received from 10.91.150.20 at: 
Value 0: 10.91.150.20
Value 1: 10.91.150.20
Value 2: 0:1:33:46.47
Value 3: .1.3.6.1.4.1.17095.0.0
Value 4: 10.91.150.20
Value 5: public
Value 6: .1.3.6.1.4.1.17095
Value 7: 
Value 8: 
Value 9: 
Value 10: 
Ent Value 0: .1.3.6.1.4.1.17095.5.4.1.0=TEST,Triggered,Triggered,21 June 2018,09:53:22


Thu Jun 21 10:53:43 2018: Unknown trap (.1.3.6.1.4.1.17095.0.0) received from 10.91.150.20 at: 
Value 0: 10.91.150.20
Value 1: 10.91.150.20
Value 2: 0:1:34:07.74
Value 3: .1.3.6.1.4.1.17095.0.0
Value 4: 10.91.150.20
Value 5: public
Value 6: .1.3.6.1.4.1.17095
Value 7: 
Value 8: 
Value 9: 
Value 10: 
Ent Value 0: .1.3.6.1.4.1.17095.5.4.1.0=TEST,OK,Recover,21 June 2018,09:53:43

scottwilkerson · Post by **scottwilkerson** » Tue Jun 26, 2018 12:27 pm

These look like Test Traps.

It may only use .1.3.6.1.4.1.17095.0.0 for test traps and uses .1.3.6.1.4.1.17095.0.1 & .1.3.6.1.4.1.17095.0.2 for the real ones.

Which you already have configured.

jameyw · Post by **jameyw** » Tue Jun 26, 2018 1:47 pm

I just named the sensor channel test. I am trying to monitor contact open/close.

scottwilkerson · Post by **scottwilkerson** » Tue Jun 26, 2018 4:36 pm

jameyw wrote:I just named the sensor channel test. I am trying to monitor contact open/close.

I see.

The only thing I can suggest would be to contact the vendor to see if they have a corrected MIB that had the right OID's

jameyw · Post by **jameyw** » Wed Jun 27, 2018 10:23 am

I changed the device to send V2 traps and what I get is much more useful. The only problem I have now is getting it to change states. I can get it to change to WARNING but I can't get it to change back to OK. It seems like it can't or won't recognize the word "Recover".

Here are the traps received:

Code: Select all

Wed Jun 27 09:32:02 2018: Unknown trap (.1.3.6.1.2.1.1.2) received from 10.91.150.20 at: 
Value 0: 10.91.150.20
Value 1: 10.91.150.20
Value 2: 0:0:01:18.47
Value 3: .1.3.6.1.2.1.1.2
Value 4: 10.91.150.20
Value 5: 
Value 6: 
Value 7: 
Value 8: 
Value 9: 
Value 10: 
Ent Value 0: .1.3.6.1.4.1.17095.5.4.1.0=911_Center
Ent Value 1: .1.3.6.1.4.1.17095.5.4.2.0=TEST
Ent Value 2: .1.3.6.1.4.1.17095.5.4.3.0=Triggered
Ent Value 3: .1.3.6.1.4.1.17095.5.4.4.0=27 June 2018
Ent Value 4: .1.3.6.1.4.1.17095.5.4.5.0=09:32:03
Ent Value 5: .1.3.6.1.4.1.17095.5.4.6.0=2


Wed Jun 27 09:32:13 2018: Unknown trap (.1.3.6.1.2.1.1.2) received from 10.91.150.20 at: 
Value 0: 10.91.150.20
Value 1: 10.91.150.20
Value 2: 0:0:01:29.11
Value 3: .1.3.6.1.2.1.1.2
Value 4: 10.91.150.20
Value 5: 
Value 6: 
Value 7: 
Value 8: 
Value 9: 
Value 10: 
Ent Value 0: .1.3.6.1.4.1.17095.5.4.1.0=911_Center
Ent Value 1: .1.3.6.1.4.1.17095.5.4.2.0=TEST
Ent Value 2: .1.3.6.1.4.1.17095.5.4.3.0=Recover
Ent Value 3: .1.3.6.1.4.1.17095.5.4.4.0=27 June 2018
Ent Value 4: .1.3.6.1.4.1.17095.5.4.5.0=09:32:14
Ent Value 5: .1.3.6.1.4.1.17095.5.4.6.0=2

And here is what I have in SNMPTT:

Code: Select all

EVENT iosensorAlert .1.3.6.1.2.1.1.2 "Status Events" Normal
FORMAT An alert has been sent by the SensorGateway on $*
EXEC /usr/local/bin/snmptraphandling.py "$1" "SNMP Trap - $2" "$s" "$@" "" "$3"
Match $3: Recover
#
#
#
EVENT iosensorAlert .1.3.6.1.2.1.1.2 "Status Events" Warning
FORMAT An alert has been sent by the SensorGateway on $*
EXEC /usr/local/bin/snmptraphandling.py "$1" "SNMP Trap - $2" "$s" "$@" "" "$3"
Match $3: Triggered

Not sure what I am missing.

Post by **cdienger** » Wed Jun 27, 2018 2:44 pm

To find a string snmptt is looking for a regex expression surrounded by () . Try the following:

EVENT iosensorAlert .1.3.6.1.2.1.1.2 "Status Events" Normal
FORMAT An alert has been sent by the SensorGateway on $*
EXEC /usr/local/bin/snmptraphandling.py "$1" "SNMP Trap - $2" "$s" "$@" "" "$3"
Match $3: (Recover)
#
#
#
EVENT iosensorAlert .1.3.6.1.2.1.1.2 "Status Events" Warning
FORMAT An alert has been sent by the SensorGateway on $*
EXEC /usr/local/bin/snmptraphandling.py "$1" "SNMP Trap - $2" "$s" "$@" "" "$3"
Match $3: (Triggered)

jameyw · Post by **jameyw** » Wed Jun 27, 2018 3:27 pm

No change. Looking in the SNMPTT log, it looks like it is processing both Normal and Warning at the same time.

Code: Select all

Wed Jun 27 15:03:41 2018 .1.3.6.1.2.1.1.2 Normal "Status Events" 10.91.150.20 - An alert has been sent by the SensorGateway on 911_Center TEST Recover 27 June 2018 15:03:41 8
Wed Jun 27 15:03:41 2018 .1.3.6.1.2.1.1.2 Warning "Status Events" 10.91.150.20 - An alert has been sent by the SensorGateway on 911_Center TEST Recover 27 June 2018 15:03:41 8

The reason it stays warning is because it is the last processed.

Post by **cdienger** » Thu Jun 28, 2018 10:40 am

We need to add the MATCH MODE option as well(http://snmptt.sourceforge.net/docs/snmp ... CONF-MATCH):

EVENT iosensorAlert .1.3.6.1.2.1.1.2 "Status Events" Normal
FORMAT An alert has been sent by the SensorGateway on $*
EXEC /usr/local/bin/bob.sh $3
Match $3:(Recover)
MATCH MODE=or
#
#
#
EVENT iosensorAlert .1.3.6.1.2.1.1.2 "Status Events" Warning
FORMAT An alert has been sent by the SensorGateway on $*
EXEC /usr/local/bin/bob.sh $3
Match $3:(Triggered)

Nagios Support Forum

SNMPTT Problems

SNMPTT Problems

Re: SNMPTT Problems

Re: SNMPTT Problems

Re: SNMPTT Problems

Re: SNMPTT Problems

Re: SNMPTT Problems

Re: SNMPTT Problems

Re: SNMPTT Problems

Re: SNMPTT Problems

Re: SNMPTT Problems