SNMP V2 Trap Errors

Description

We are experiencing a problem processing SNMP V2 traps for a new piece of
telecommunications equipment. The trapd log contains the following information:

2005-01-05 12:04:58,546 DEBUG [TrapQueueProcessor] TrapQueueProcessor: V2
trap - trapInterface: 192.168.71.3
2005-01-05 12:05:00,117 DEBUG [TrapQueueProcessor] TrapQueueProcessor: V2
trap numVars or pdu length: 10
2005-01-05 12:05:00,117 DEBUG [TrapQueueProcessor] TrapQueueProcessor: V2
trap first varbind value: 1000
2005-01-05 12:05:00,117 ERROR [TrapQueueProcessor] TrapQueueProcessor:
Unexpected error processing V2 trap
java.lang.ClassCastException
at
org.opennms.netmgt.trapd.TrapQueueProcessor.process(TrapQueueProcessor.java:
305)
at
org.opennms.netmgt.trapd.TrapQueueProcessor.run(TrapQueueProcessor.java:971)
at java.lang.Thread.run(Thread.java:534)

The first varbind appears to have been decoded properly. As near as I can
tell, the exception occurs when decoding the second varbind that has an OID
of 1.3.6.1.6.3.1.1.4.1.0 and the value is a type OBJECTID which is
1.3.6.1.4.1.1751.1.50.6.2.7

The following is a decode of the packet actually received:

No. Time Source Destination Protocol Info
9659 121.268951 192.168.71.3 192.168.90.150 SNMP TRAP-V2
1.3.6.1.2.1.1.3.0 1.3.6.1.6.3.1.1.4.1.0 1.3.6.1.4.1.1751.1.50.6.2.1 1.3.6.1.4.1
.1751.1.50.6.2.2 1.3.6.1.4.1.1751.1.50.6.1.2.1.4 1.3.6.1.4.1.1751.1.50.6.1.2.1.5
1.3.6.1.4.1.1751.1.50.6.1.2.1.6 1.3.6.1.4.1.1751.1.50.6.2.4 1.3.6.1.4.1.1751.1.
50.6.2.3 1.3.6.1.4.1.1751.1.50.6.1.2.1.9

Frame 9659 (283 bytes on wire, 283 bytes captured)
Arrival Time: Jan 5, 2005 12:10:06.129481000
Time delta from previous packet: 78.343308000 seconds
Time since reference or first frame: 121.268951000 seconds
Frame Number: 9659
Packet Length: 283 bytes
Capture Length: 283 bytes
Ethernet II, Src: 00:06:28:dc:e1:1d, Dst: 00:07:e9:83:ae:00
Destination: 00:07:e9:83:ae:00 (shark.operations.gci.com)
Source: 00:06:28:dc:e1:1d (192.168.90.149)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.71.3 (192.168.71.3), Dst Addr: 192.168.90.1
50 (192.168.90.150)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 269
Identification: 0x8193 (33171)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 249
Protocol: UDP (0x11)
Header checksum: 0xdc61 (correct)
Source: 192.168.71.3 (192.168.71.3)
Destination: 192.168.90.150 (192.168.90.150)
User Datagram Protocol, Src Port: 45048 (45048), Dst Port: snmptrap (162)
Source port: 45048 (45048)
Destination port: snmptrap (162)
Length: 249
Checksum: 0x377c (correct)
Simple Network Management Protocol
Version: 2C (1)
Community: anypath
PDU type: TRAP-V2 (7)
Request Id: 0x00000000
Error Status: NO ERROR (0)
Error Index: 0
Object identifier 1: 1.3.6.1.2.1.1.3.0
Value: INTEGER: 1000 (0x3e8)
Object identifier 2: 1.3.6.1.6.3.1.1.4.1.0
Value: OBJECTID: 1.3.6.1.4.1.1751.1.50.6.2.7
Object identifier 3: 1.3.6.1.4.1.1751.1.50.6.2.1
Value: INTEGER: 1001 (0x3e9)
Object identifier 4: 1.3.6.1.4.1.1751.1.50.6.2.2
Value: INTEGER: 1 (0x1)
Object identifier 5: 1.3.6.1.4.1.1751.1.50.6.1.2.1.4
Value: INTEGER: 50 (0x32)
Object identifier 6: 1.3.6.1.4.1.1751.1.50.6.1.2.1.5
Value: OCTET STRING: ts01
Object identifier 7: 1.3.6.1.4.1.1751.1.50.6.1.2.1.6
Value: INTEGER: 4 (0x4)
Object identifier 8: 1.3.6.1.4.1.1751.1.50.6.2.4
Value: IPADDR: 192.168.037.050
Object identifier 9: 1.3.6.1.4.1.1751.1.50.6.2.3
Value: INTEGER: 5 (0x5)
Object identifier 10: 1.3.6.1.4.1.1751.1.50.6.1.2.1.9
Value: INTEGER: 3 (0x3)

0000 00 07 e9 83 ae 00 00 06 28 dc e1 1d 08 00 45 00 ........(.....E.
0010 01 0d 81 93 40 00 f9 11 dc 61 c0 a8 47 03 c0 a8 ....@....a..G...
0020 5a 96 af f8 00 a2 00 f9 37 7c 30 81 ee 02 01 01 Z.......7|0.....
0030 04 07 61 6e 79 70 61 74 68 a7 81 df 02 01 00 02 ..anypath.......
0040 01 00 02 01 00 30 81 d3 30 0e 06 08 2b 06 01 02 .....0..0...+...
0050 01 01 03 00 02 02 03 e8 30 1a 06 0a 2b 06 01 06 ........0...+...
0060 03 01 01 04 01 00 06 0c 2b 06 01 04 01 8d 57 01 ........+.....W.
0070 32 06 02 07 30 12 06 0c 2b 06 01 04 01 8d 57 01 2...0...+.....W.
0080 32 06 02 01 02 02 03 e9 30 11 06 0c 2b 06 01 04 2.......0...+...
0090 01 8d 57 01 32 06 02 02 02 01 01 30 13 06 0e 2b ..W.2......0...+
00a0 06 01 04 01 8d 57 01 32 06 01 02 01 04 02 01 32 .....W.2.......2
00b0 30 16 06 0e 2b 06 01 04 01 8d 57 01 32 06 01 02 0...+.....W.2...
00c0 01 05 04 04 74 73 30 31 30 13 06 0e 2b 06 01 04 ....ts010...+...
00d0 01 8d 57 01 32 06 01 02 01 06 02 01 04 30 14 06 ..W.2........0..
00e0 0c 2b 06 01 04 01 8d 57 01 32 06 02 04 40 04 c0 .+.....W.2...@..
00f0 a8 25 32 30 11 06 0c 2b 06 01 04 01 8d 57 01 32 .%20...+.....W.2
0100 06 02 03 02 01 05 30 13 06 0e 2b 06 01 04 01 8d ......0...+.....
0110 57 01 32 06 01 02 01 09 02 01 03 W.2........

This is the only network element that I currently have configured to send traps
using SNMP V2. All of the network elements running SNMP V1 appear to be
decoded properly.

Environment

Operating System: Linux Platform: PC

Acceptance / Success Criteria

None

Attachments

1

Lucidchart Diagrams

Activity

Tarus Balog February 8, 2005 at 3:37 PM

Fix confirmed by client.

Jim Jarvis February 8, 2005 at 11:09 AM

The problem is no longer occurring. We have generated a number of conditions
that would generate the error condition and all traps have been processed
sucessfully.

Thanks.

Jarvis

Tarus Balog February 8, 2005 at 10:00 AM

Can you tell me if this is still happening? Shark is running 1.1.5 which should include the fix. I'd like to
close this bug for 1.2.0.

Tarus Balog January 11, 2005 at 5:27 PM

Created an attachment (id=138)
Patch against CVS HEAD

Tarus Balog January 11, 2005 at 5:26 PM

I have a fix for this. Testing at customer site and will commit if it works.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

PagerDuty

Created January 6, 2005 at 3:29 PM
Updated January 27, 2017 at 4:30 PM
Resolved February 8, 2005 at 4:37 PM