[Snmptt-users] R: snmptrapd snmptt carriage return line feed inside trap text string [Solved]
Brought to you by:
alex_b
Menu
▾
▴
[Snmptt-users] R: snmptrapd snmptt carriage return line feed inside trap text string [Solved]
|
From: Diego C. <Die...@de...> - 2013-06-04 13:42:56
|
Hello, looking in the SNMPTT ticket repository I found that this problem was already solved on 2010-05-22 "#5 Fix multi-line traps from NET-SNMP 5.4" (see http://sourceforge.net/p/snmptt/patches/5/ ) The patch is available for download and in snmptt_1.4beta2 So I'm going to uninstall snmptt_1.3 replacing with snmptt_1.4beta2 SNMPTT_1.4beta2 Release Notes: * Added snmptt.ini option net_snmp_perl_cache_enable to enable caching of Net-SNMP Perlmodule OID and ENUM translations. This may speed up translations and reduce CPU load when net_snmp_perl_enable and translate_* options are enabled. * Fixed bug with snmptthandler-embedded where IP addresses and OIDs were not being detected properly because they contained 'OID:', 'IpAddress:' etc. * Fixed bug with MATCH. The PREEXEC $p variable could not be used with MATCH. PREEXEC is now executed first if MATCH contains $p. * Fixed bug with syslog. Log entries were supposed to be logged with snmptt[pid] but instad of the pid it was actually the effective user ID (2980512). * Fixed bug where the hostname is not detected properly when snmptrapd is configured to not use DNS. * Fixed bug where if the spool directory is not defined, files may be deleted from the wrong folder (3020696). * Fixed bug with syslog logging. Function was not being called properly (3166749). * Fixed bug with MATCH where number ranges were not working (3397982). **** Fixed bug with multi-line traps (2915658). **** YES! * Fixed bug with LOGONLY severity. EXEC was being executed even if the trap had a severity of LOGONLY (3567744). * Fixed bug with snmptt hanging if the log message sent to syslog contained a % symbol. All %'s are now escaped before sending to syslog (3567748). * Fixed possible bug with MySQL. Put CONNECT string on one line. * Fixed bug with not being able to write to the debug log file when running snmptt as non-root if the debug file didn't already exist with the correct permissions at startup. The ownership of snmptt.debug is now set to daemon_uid before switching to the new uid. Patch 3423525. * Installation documentation updates (bug 3425999). Thanks to all very much Best regards Diego Da: Diego Campoli [mailto:Die...@de...] Inviato: martedì 4 giugno 2013 13:03 A: net...@li... Oggetto: snmptrapd snmptt carriage return line feed inside trap text string Hello, first of all thank you in advance for the time you spend to read this long question, then excuse me for my bad exposition, I don't speak English very well :) I want to tell you a problem that I can't resolve, hope you can help me. I have a Nagios station configured for active and passive monitoring checks installed on Vmware Virtual Machine with Ubuntu 12.04.1 LTS. I need to receive trap with Nagios so I installed and configured Net-SNMP / UCD-SNMP packages and snmptrapd. Started snmptrapd: sudo snmptrapd -A -n -d -On -f -d -Lf "/var/log/snmptt/snmptrapd.log" After converted MIB with SNMPTTCONVERTMIB I started to receive traps from my network devices. All works fine, and Nagios handles traps!!!! But... There are traps that SNMPTT can't resolve :( I have several network devices like DELL Switch Powerconnect 5448 (but I suppose the problem is for all the DELL Powerconnect54xx switches and maybe alse other devices) configured for sending snmp trap to the monitoring station. Most of the traps are correctly handled (as linkUp or linkDown port status, etc.) but there are traps that snmptt can't handle. For example this trap, defined in the RADLAN-MIB: ================================================================================ ... rldot1dStpPortStateForwarding TRAP-TYPE ENTERPRISE rnd VARIABLES { rndErrorDesc, rndErrorSeverity, rldot1dStpTrapVrblifIndex, rldot1dStpTrapVrblVID } DESCRIPTION "The trap is sent by a bridge when any of its configured ports transitions from the Learning state to the Forwarding state." ::= 151 ... ================================================================================ This is the definition inside configuration file created by snmpttconvertmib: ================================================================================ ... # EVENT rldot1dStpPortStateForwarding .1.3.6.1.4.1.89.0.151 "Status Events" Normal FORMAT The trap is sent by a bridge when any of its configured ports $* EXEC /usr/local/nagios/libexec/eventhandlers/submit_check_result $r Trap 1 "The trap is sent by a bridge when any of its configured ports $*" SDESC The trap is sent by a bridge when any of its configured ports transitions from the Learning state to the Forwarding state. Variables: 1: rndErrorDesc 2: rndErrorSeverity 3: rldot1dStpTrapVrblifIndex 4: rldot1dStpTrapVrblVID EDESC # ... ================================================================================ And this is what happen when the trap is received by SNMPTT (snmptt.debug): ================================================================================ ********** SNMPTT v1.3 started: Tue May 28 02:59:20 2013 ********** ********** Net-SNMP version 5.0403 Perl module enabled ********** ********** MIBS: ALL ********** Reading trap. Current time: Tue May 28 02:59:20 2013 Multi-line value detected - merging onto one line... Raw trap passed from snmptrapd: UDP: [172.16.254.29]:161->[172.16.20.65]:162 UDP: [172.16.254.29]:161->[172.16.20.65]:162 .1.3.6.1.2.1.1.3.0 0:4:57:47.50 .1.3.6.1.6.3.1.1.4.1.0 .1.3.6.1.4.1.89.0.151 .1.3.6.1.4.1.89.2.3.1.0 "%STP-W-PORTSTATUS: g9: STP status Forwarding " .1.3.6.1.4.1.89.2.3.2.0 1 .1.3.6.1.4.1.89.57.2.8.1.0 9 .1.3.6.1.4.1.89.57.2.8.2.0 0 .1.3.6.1.6.3.18.1.3.0 172.16.254.29 .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.89 Items passed from snmptrapd: value 0: UDP: [172.16.254.29]:161->[172.16.20.65]:162 value 1: 172.16.254.29 value 2: .1.3.6.1.2.1.1.3.0 value 3: 0:4:57:47.50 value 4: .1.3.6.1.6.3.1.1.4.1.0 value 5: .1.3.6.1.4.1.89.0.151 value 6: .1.3.6.1.4.1.89.2.3.1.0 value 7: %STP-W-PORTSTATUS: g9: STP status Forwarding " .1.3.6.1.4.1.89.2.3.2.0 1 .1.3.6.1.4.1.89.57.2.8.1.0 9 .1.3.6.1.4.1.89.57.2.8.2.0 0 .1.3.6.1.6.3.18.1.3.0 172.16.254.29 .1.3.6.1.6.3.18.1.4.0 "public value 8: .1.3.6.1.6.3.1.1.4.3.0 value 9: .1.3.6.1.4.1.89 Agent IP address was blank, so setting to the same as the host IP address of 172.16.254.29 Agent IP address (172.16.254.29) is the same as the host IP, so copying the host name: UDP: [172.16.254.29]:161->[172.16.20.65]:162 Trap received from UDP: [172.16.254.29]:161->[172.16.20.65]:162: .1.3.6.1.4.1.89.0.151 0: hostname 1: ip address 2: uptime 3: trapname / OID 4: ip address from trap agent 5: trap community string 6: enterprise 7: securityEngineID (snmptthandler-embedded required) 8: securityName (snmptthandler-embedded required) 9: contextEngineID (snmptthandler-embedded required) 10: contextName (snmptthandler-embedded required) 0+: passed variables Value 0: UDP: [172.16.254.29]:161->[172.16.20.65]:162 Value 1: 172.16.254.29 Value 2: 0:4:57:47.50 Value 3: .1.3.6.1.4.1.89.0.151 Value 4: 172.16.254.29 Value 5: Value 6: .1.3.6.1.4.1.89 Value 7: Value 8: Value 9: Value 10: Agent dns name: UDP: [172.16.254.29]:161->[172.16.20.65]:162 Ent Value 0 ($1): .1.3.6.1.4.1.89.2.3.1.0=%STP-W-PORTSTATUS: g9: STP status Forwarding " .1.3.6.1.4.1.89.2.3.2.0 1 .1.3.6.1.4.1.89.57.2.8.1.0 9 .1.3.6.1.4.1.89.57.2.8.2.0 0 .1.3.6.1.6.3.18.1.3.0 172.16.254.29 .1.3.6.1.6.3.18.1.4.0 "public ******************************************************************************** ================================================================================ As you can see the 4 expected variables are not recognized by SNMPTT. SNMPTT put all variables and values inside the first variable ($1) The problem I think is the carriage return/line feed inside the packet sent by the DELL Switch: This is the packet dump from snmptrapd logfile: ================================================================================ Received 160 byte packet from UDP: [172.16.254.29]:161->[172.16.20.65]:162 0000: 30 81 9D 02 01 00 04 06 70 75 62 6C 69 63 A4 81 0.......public.. 0016: 8F 06 06 2B 06 01 04 01 59 40 04 AC 10 FE 1D 02 ...+....Y@<mailto:...+....Y@>...... 0032: 01 06 02 02 00 97 43 03 45 40 BA 30 73 30 3C 06 ......C.E@.0s0<<mailto:......C.E@.0s0%3c>. 0048: 0A 2B 06 01 04 01 59 02 03 01 00 04 2E 25 53 54 .+....Y......%ST 0064: 50 2D 57 2D 50 4F 52 54 53 54 41 54 55 53 3A 20 P-W-PORTSTATUS: 0080: 67 39 3A 20 53 54 50 20 73 74 61 74 75 73 20 46 g9: STP status F 0096: 6F 72 77 61 72 64 69 6E 67 0D 0A 30 0F 06 0A 2B orwarding..0...+ 0112: 06 01 04 01 59 02 03 02 00 02 01 01 30 10 06 0B ....Y.......0... 0128: 2B 06 01 04 01 59 39 02 08 01 00 02 01 09 30 10 +....Y9.......0. 0144: 06 0B 2B 06 01 04 01 59 39 02 08 02 00 02 01 00 ..+....Y9....... 2013-05-28 10:37:47 172.16.254.29(via UDP: [172.16.254.29]:161->[172.16.20.65]:162) TRAP, SNMP v1, community public .1.3.6.1.4.1.89 Enterprise Specific Trap (151) Uptime: 12:36:25.54 .1.3.6.1.4.1.89.2.3.1.0 = STRING: "%STP-W-PORTSTATUS: g9: STP status Forwarding " .1.3.6.1.4.1.89.2.3.2.0 = INTEGER: 1 .1.3.6.1.4.1.89.57.2.8.1.0 = INTEGER: 9 .1.3.6.1.4.1.89.57.2.8.2.0 = INTEGER: 0 ================================================================================ You can see the special characters 0D 0A (Carriage Return / Line Feed) at the end of the string: "%STP-W-PORTSTATUS: g9: STP status Forwarding" I suppose there is the problem. Why DELL network devices put carriage returns and a line feed inside a trap? This is a question like "Does the Tathagata (Buddha) exist after death?" and I do not want investigate it now >:-( I also configured snmptrapd to Display string values as Hex strings (snmptrapd -Onx) and this works for SNMPTT, but I tried only for diagnostic reasons, it can't be a solution because is intelligible for human beings that cannot read hexadecimal notations :) ================================================================================ ********** SNMPTT v1.3 started: Tue May 28 10:56:28 2013 ********** ********** Net-SNMP version 5.0403 Perl module enabled ********** ********** MIBS: ALL ********** Reading trap. Current time: Tue May 28 10:56:29 2013 Multi-line value detected - merging onto one line... Raw trap passed from snmptrapd: UDP: [172.16.254.29]:161->[172.16.20.65]:162 UDP: [172.16.254.29]:161->[172.16.20.65]:162 .1.3.6.1.2.1.1.3.0 0:12:55:06.02 .1.3.6.1.6.3.1.1.4.1.0 .1.3.6.1.4.1.89.0.151 .1.3.6.1.4.1.89.2.3.1.0 "25 53 54 50 2D 57 2D 50 4F 52 54 53 54 41 54 55 53 3A 20 67 39 3A 20 53 54 50 20 73 74 61 74 75 73 20 46 6F 72 77 61 72 64 69 6E 67 0D 0A " .1.3.6.1.4.1.89.2.3.2.0 1 .1.3.6.1.4.1.89.57.2.8.1.0 9 .1.3.6.1.4.1.89.57.2.8.2.0 0 .1.3.6.1.6.3.18.1.3.0 172.16.254.29 .1.3.6.1.6.3.18.1.4.0 "70 75 62 6C 69 63 " .1.3.6.1.6.3.1.1.4.3.0 .1.3.6.1.4.1.89 Items passed from snmptrapd: value 0: UDP: [172.16.254.29]:161->[172.16.20.65]:162 value 1: 172.16.254.29 value 2: .1.3.6.1.2.1.1.3.0 value 3: 0:12:55:06.02 value 4: .1.3.6.1.6.3.1.1.4.1.0 value 5: .1.3.6.1.4.1.89.0.151 value 6: .1.3.6.1.4.1.89.2.3.1.0 value 7: 25 53 54 50 2D 57 2D 50 4F 52 54 53 54 41 54 55 53 3A 20 67 39 3A 20 53 54 50 20 73 74 61 74 75 73 20 46 6F 72 77 61 72 64 69 6E 67 0D 0A value 8: .1.3.6.1.4.1.89.2.3.2.0 value 9: 1 value 10: .1.3.6.1.4.1.89.57.2.8.1.0 value 11: 9 value 12: .1.3.6.1.4.1.89.57.2.8.2.0 value 13: 0 value 14: .1.3.6.1.6.3.18.1.3.0 value 15: 172.16.254.29 value 16: .1.3.6.1.6.3.18.1.4.0 value 17: 70 75 62 6C 69 63 value 18: .1.3.6.1.6.3.1.1.4.3.0 value 19: .1.3.6.1.4.1.89 Agent IP address (172.16.254.29) is the same as the host IP, so copying the host name: UDP: [172.16.254.29]:161->[172.16.20.65]:162 Trap received from UDP: [172.16.254.29]:161->[172.16.20.65]:162: .1.3.6.1.4.1.89.0.151 0: hostname 1: ip address 2: uptime 3: trapname / OID 4: ip address from trap agent 5: trap community string 6: enterprise 7: securityEngineID (snmptthandler-embedded required) 8: securityName (snmptthandler-embedded required) 9: contextEngineID (snmptthandler-embedded required) 10: contextName (snmptthandler-embedded required) 0+: passed variables Value 0: UDP: [172.16.254.29]:161->[172.16.20.65]:162 Value 1: 172.16.254.29 Value 2: 0:12:55:06.02 Value 3: .1.3.6.1.4.1.89.0.151 Value 4: 172.16.254.29 Value 5: 70 75 62 6C 69 63 Value 6: .1.3.6.1.4.1.89 Value 7: Value 8: Value 9: Value 10: Agent dns name: UDP: [172.16.254.29]:161->[172.16.20.65]:162 Ent Value 0 ($1): .1.3.6.1.4.1.89.2.3.1.0=25 53 54 50 2D 57 2D 50 4F 52 54 53 54 41 54 55 53 3A 20 67 39 3A 20 53 54 50 20 73 74 61 74 75 73 20 46 6F 72 77 61 72 64 69 6E 67 0D 0A Ent Value 1 ($2): .1.3.6.1.4.1.89.2.3.2.0=1 Ent Value 2 ($3): .1.3.6.1.4.1.89.57.2.8.1.0=9 Ent Value 3 ($4): .1.3.6.1.4.1.89.57.2.8.2.0=0 ================================================================================ So as you can see Hex strings variables are correctly handled. Thank you for your time, I wait you for a feedback :) Best regards Diego |
