Re: snmptrapd snmptt carriage return line feed inside trap text string
Chris Bartram <[email protected]>
| Newsgroups | gmane.network.net-snmp.user |
|---|---|
| Message-ID | <[email protected]> |
One of the things I discovered after writing lots of trap handlers for Net-SNMP is that several devices do generates multiline OID values - and that in your parser you need to check for a leading quote in the value field - and if you find it you must keep reading in data and new lines (and concatenating what you read in) until you find that closing quote. After that return to reading lines and splitting them into oid/value pairs. The data you show below matches what I've seen from several traps (Dell and others). Modify your trap handler to gobble up data until the ending quote and you'll be fine. -Chris Bartram "The purpose of life is not to be happy. It is to be useful, to be honorable, to be compassionate, to have it make some difference that you have lived and lived well". (Ralph Waldo Emerson) >________________________________ > From: Diego Campoli <[email protected]> >To: "[email protected]" <[email protected]> >Sent: Wednesday, May 29, 2013 5:22 AM >Subject: 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@...... >0032: 01 06 02 02 00 97 43 03 45 40 BA 30 73 30 3C 06 [email protected]<. >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. >I don’t know if the problem is snmptrapd output (maybe it should remove cr/lf special characters from strings, or smptt interpreter) >Thank you for your time, I wait you for a feedback :) >Best regards >Diego > >------------------------------------------------------------------------------ >Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >Get 100% visibility into your production application - at no cost. >Code-level diagnostics for performance bottlenecks with <2% overhead >Download for free and get started troubleshooting in minutes. >http://p.sf.net/sfu/appdyn_d2d_ap1 >_______________________________________________ >Net-snmp-users mailing list >[email protected] >Please see the following page to unsubscribe or change other options: >https://lists.sourceforge.net/lists/listinfo/net-snmp-users > > > ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users