Skip Menu |

This queue is for tickets about the Net-SNMP CPAN distribution.

Report information
The Basics
Id: 74944
Status: resolved
Worked: 12 min
Priority: 0/
Queue: Net-SNMP

People
Owner: dtown [...] cpan.org
Requestors: henrik.berg [...] barret.se
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Problem with 6 byte Counter32
Date: Mon, 13 Feb 2012 16:10:05 +0000
To: "bug-Net-SNMP [...] rt.cpan.org" <bug-Net-SNMP [...] rt.cpan.org>
From: Henrik Berg <henrik.berg [...] barret.se>
I hope I'm not completely off here. When polling a small number of machines I get "The Counter length is too long (6 bytes)". I have found that it is Counter32 values that look like this example: oid: 1.3.6.1.2.1.2.2.1.10.2 bytes: 0 161 168 76 7 181 from what I can tell the first 0 means it's a positive number but the next byte I have no idea. I have sniffed an snmpwalk and it gets the same bytes but produces a correct value. It's always 161 and if I splice it away it produces the correct value. Is it some kind of flag? I quickly looked through a page on ASN.1 encoding but could not find anything similar. I'm not sure where the problem lies so if it's in the other end then I'm sorry but since it works in snmpwalk and an older module I've used I gave this a shot. I'm afraid I can't give out an IP to test against since it's customer equipment. Version: Net-SNMP-v6.0.1 Perl version: v5.8.8 OS: Redhat EL5
Subject: SV: [rt.cpan.org #74944] AutoReply: Problem with 6 byte Counter32
Date: Wed, 15 Feb 2012 09:04:56 +0000
To: "bug-Net-SNMP [...] rt.cpan.org" <bug-Net-SNMP [...] rt.cpan.org>
From: Henrik Berg <henrik.berg [...] barret.se>
I might have spoken too soon. The erroneous byte has now increased to 162. Is this simply a Counter64 identifying itself as a Counter32? (type 0x41) So that the snmpwalk command in fact isn't showing the correct number, but instead a truncated one.
On Wed Feb 15 04:05:14 2012, henrik.berg@barret.se wrote: Show quoted text
> I might have spoken too soon. The erroneous byte has now increased to > 162. > Is this simply a Counter64 identifying itself as a Counter32? > (type 0x41) > So that the snmpwalk command in fact isn't showing the > correct number, but instead a truncated one.
Can you enable debugging by adding "-debug => 0xff" to the session constructor and include the output in the ticket? A properly encoded Counter32 will never be longer than 5 bytes.
Subject: SV: [rt.cpan.org #74944] Problem with 6 byte Counter32
Date: Wed, 15 Feb 2012 12:52:59 +0000
To: "bug-Net-SNMP [...] rt.cpan.org" <bug-Net-SNMP [...] rt.cpan.org>
From: Henrik Berg <henrik.berg [...] barret.se>
Sure thing. Here is a bulkwalk of 1.3.6.1.2.1.2.2.1.10 where .1 works but .2 fails. I've just replaced the community and ip with X's. A get of 1.3.6.1.2.1.2.2.1.10.2 specifically breaks in the same way. A quick question as well, isn't Counter32 supposed to be unsigned? Why then handle it like an Integer32? Thanks. debug: [440] Net::SNMP::Dispatcher::_event_insert(): created new head and tail [ARRAY(0xae2aea0)] debug: [687] Net::SNMP::Message::send(): transport address X.X.X.X:161 debug: [2060] Net::SNMP::Message::_buffer_dump(): 45 bytes [0000] 30 2B 02 01 01 04 07 XX XX XX XX XX XX XX A5 1D 0+.....XXXXXXX.. [0016] 02 04 24 AC 60 A3 02 01 00 02 01 19 30 0F 30 0D ..$.`.......0.0. [0032] 06 09 2B 06 01 02 01 02 02 01 0A 05 00 ..+.......... debug: [200] Net::SNMP::Dispatcher::register(): added handler for descriptor [3] debug: [462] Net::SNMP::Dispatcher::_event_insert(): modified tail [ARRAY(0xae2b370)] debug: [535] Net::SNMP::Dispatcher::_event_delete(): deleted [ARRAY(0xae2aea0)], defined new head [ARRAY(0xae2b370)] debug: [596] Net::SNMP::Dispatcher::_event_handle(): event [ARRAY(0xae2b370)], timeout = 9.9998 debug: [621] Net::SNMP::Dispatcher::_event_handle(): descriptor [3] ready for read debug: [711] Net::SNMP::Message::recv(): transport address X.X.X.194:161 debug: [2060] Net::SNMP::Message::_buffer_dump(): 491 bytes [0000] 30 82 01 E7 02 01 01 04 07 XX XX XX XX XX XX XX 0........XXXXXXX [0016] A2 82 01 D7 02 04 24 AC 60 A3 02 01 00 02 01 00 ......$.`....... [0032] 30 82 01 C7 30 13 06 0A 2B 06 01 02 01 02 02 01 0...0...+....... [0048] 0A 01 41 05 00 CC 99 CA 6D 30 14 06 0A 2B 06 01 ..A.....m0...+.. [0064] 02 01 02 02 01 0A 02 41 06 00 A2 0C 46 34 9D 30 .......A....F4.0 [0080] 0F 06 0A 2B 06 01 02 01 02 02 01 0A 03 41 01 00 ...+.........A.. [0096] 30 12 06 0A 2B 06 01 02 01 02 02 01 0B 01 41 04 0...+.........A. [0112] 01 31 42 C7 30 13 06 0A 2B 06 01 02 01 02 02 01 .1B.0...+....... [0128] 0B 02 41 05 00 F4 04 25 8A 30 0F 06 0A 2B 06 01 ..A....%.0...+.. [0144] 02 01 02 02 01 0B 03 41 01 00 30 0F 06 0A 2B 06 .......A..0...+. [0160] 01 02 01 02 02 01 0D 01 41 01 00 30 0F 06 0A 2B ........A..0...+ [0176] 06 01 02 01 02 02 01 0D 02 41 01 00 30 0F 06 0A .........A..0... [0192] 2B 06 01 02 01 02 02 01 0D 03 41 01 00 30 0F 06 +.........A..0.. [0208] 0A 2B 06 01 02 01 02 02 01 0E 01 41 01 00 30 0F .+.........A..0. [0224] 06 0A 2B 06 01 02 01 02 02 01 0E 02 41 01 00 30 ..+.........A..0 [0240] 0F 06 0A 2B 06 01 02 01 02 02 01 0E 03 41 01 00 ...+.........A.. [0256] 30 13 06 0A 2B 06 01 02 01 02 02 01 10 01 41 05 0...+.........A. [0272] 00 CC 99 CA 6D 30 13 06 0A 2B 06 01 02 01 02 02 ....m0...+...... [0288] 01 10 02 41 05 29 FF EF EF 0C 30 0F 06 0A 2B 06 ...A.)....0...+. [0304] 01 02 01 02 02 01 10 03 41 01 00 30 12 06 0A 2B ........A..0...+ [0320] 06 01 02 01 02 02 01 11 01 41 04 01 31 42 C7 30 .........A..1B.0 [0336] 12 06 0A 2B 06 01 02 01 02 02 01 11 02 41 04 74 ...+.........A.t [0352] 76 9E 10 30 0F 06 0A 2B 06 01 02 01 02 02 01 11 v..0...+........ [0368] 03 41 01 00 30 0F 06 0A 2B 06 01 02 01 02 02 01 .A..0...+....... [0384] 13 01 41 01 00 30 0F 06 0A 2B 06 01 02 01 02 02 ..A..0...+...... [0400] 01 13 02 41 01 00 30 0F 06 0A 2B 06 01 02 01 02 ...A..0...+..... [0416] 02 01 13 03 41 01 00 30 0F 06 0A 2B 06 01 02 01 ....A..0...+.... [0432] 02 02 01 14 01 41 01 00 30 0F 06 0A 2B 06 01 02 .....A..0...+... [0448] 01 02 02 01 14 02 41 01 00 30 0F 06 0A 2B 06 01 ......A..0...+.. [0464] 02 01 02 02 01 14 03 41 01 00 30 0F 06 0A 2B 06 .......A..0...+. [0480] 01 02 01 02 02 01 15 01 42 01 00 ........B.. debug: [965] Net::SNMP::PDU::_process_var_bind_list(): { 1.3.6.1.2.1.2.2.1.10.1 => Counter: 3432630893 } error: [1438] Net::SNMP::Message::_process_integer32(): The Counter length is too long (6 bytes) error: [299] Net::SNMP::MessageProcessing::prepare_data_elements(): The Counter length is too long (6 bytes) error: [398] Net::SNMP::Dispatcher::_transport_response_received(): The Counter length is too long (6 bytes) debug: [517] Net::SNMP::Dispatcher::_event_delete(): deleted [ARRAY(0xae2b370)], list is now empty debug: [239] Net::SNMP::Dispatcher::deregister(): removed handler for descriptor [3] error: [2363] Net::SNMP::__ANON__(): The Counter length is too long (6 bytes)
The response you are receiving is incorrectly encoded. The data at position 71 is "41 06 00 A2 0C 46 34 9D". The second byte represents the invalid length of 6. You cannot create a valid 32 bits value from 6 bytes without overflow. Signed and unsigned value are encoded the same way according to the Basic Encoding Rules (BER) of ANS.1. The first bit in the encoding is a sign bit. If it is one, then the value is negative. To properly encode a large 32 bit unsigned value (which has the first bit set) you have to prepend a byte with a value of 0 to the encoding. The length in this case would be 5, with the first byte required to have a value of 0. The _process_integer32() method handles this case. You said "snmpwalk" works. Is it using SNMPv1 or SNMPv2? Can you try using SNMPv1 with Net::SNMP? I have seen agents with broken v2 implementation while v1 works fine. Either way this is a problem with the agent, not Net::SNMP. On Wed Feb 15 07:53:13 2012, henrik.berg@barret.se wrote: Show quoted text
> Sure thing. > Here is a bulkwalk of 1.3.6.1.2.1.2.2.1.10 where .1 > works but .2 fails. > I've just replaced the community and ip with X's. > A get of 1.3.6.1.2.1.2.2.1.10.2 specifically breaks in the same way. > A quick question as well, isn't Counter32 supposed to be unsigned? > Why then handle it like an Integer32? > > Thanks. > > debug: [440] > Net::SNMP::Dispatcher::_event_insert(): created new head and tail > [ARRAY(0xae2aea0)] > debug: [687] Net::SNMP::Message::send(): transport > address X.X.X.X:161 > debug: [2060] Net::SNMP::Message::_buffer_dump(): > 45 bytes > [0000] 30 2B 02 01 01 04 07 XX XX XX XX XX XX XX A5 1D > 0+.....XXXXXXX.. > [0016] 02 04 24 AC 60 A3 02 01 00 02 01 19 30 0F > 30 0D ..$.`.......0.0. > [0032] 06 09 2B 06 01 02 01 02 02 01 0A > 05 00 ..+.......... > debug: [200] > Net::SNMP::Dispatcher::register(): added handler for descriptor [3] > debug: [462] Net::SNMP::Dispatcher::_event_insert(): modified tail > [ARRAY(0xae2b370)] > debug: [535] > Net::SNMP::Dispatcher::_event_delete(): deleted [ARRAY(0xae2aea0)], > defined new head [ARRAY(0xae2b370)] > debug: [596] > Net::SNMP::Dispatcher::_event_handle(): event [ARRAY(0xae2b370)], > timeout = 9.9998 > debug: [621] Net::SNMP::Dispatcher::_event_handle(): > descriptor [3] ready for read > debug: [711] > Net::SNMP::Message::recv(): transport address X.X.X.194:161 > debug: > [2060] Net::SNMP::Message::_buffer_dump(): 491 bytes > [0000] 30 82 01 > E7 02 01 01 04 07 XX XX XX XX XX XX XX 0........XXXXXXX > [0016] > A2 82 01 D7 02 04 24 AC 60 A3 02 01 00 02 01 00 ......$.`....... > [0032] 30 82 01 C7 30 13 06 0A 2B 06 01 02 01 02 02 01 > 0...0...+....... > [0048] 0A 01 41 05 00 CC 99 CA 6D 30 14 06 0A 2B > 06 01 ..A.....m0...+.. > [0064] 02 01 02 02 01 0A 02 41 06 00 A2 > 0C 46 34 9D 30 .......A....F4.0 > [0080] 0F 06 0A 2B 06 01 02 01 > 02 02 01 0A 03 41 01 00 ...+.........A.. > [0096] 30 12 06 0A 2B > 06 01 02 01 02 02 01 0B 01 41 04 0...+.........A. > [0112] 01 31 > 42 C7 30 13 06 0A 2B 06 01 02 01 02 02 01 .1B.0...+....... > [0128] 0B 02 41 05 00 F4 04 25 8A 30 0F 06 0A 2B 06 01 > ..A....%.0...+.. > [0144] 02 01 02 02 01 0B 03 41 01 00 30 0F 06 0A > 2B 06 .......A..0...+. > [0160] 01 02 01 02 02 01 0D 01 41 01 00 > 30 0F 06 0A 2B ........A..0...+ > [0176] 06 01 02 01 02 02 01 0D > 02 41 01 00 30 0F 06 0A .........A..0... > [0192] 2B 06 01 02 01 > 02 02 01 0D 03 41 01 00 30 0F 06 +.........A..0.. > [0208] 0A 2B > 06 01 02 01 02 02 01 0E 01 41 01 00 30 0F .+.........A..0. > [0224] 06 0A 2B 06 01 02 01 02 02 01 0E 02 41 01 00 30 > ..+.........A..0 > [0240] 0F 06 0A 2B 06 01 02 01 02 02 01 0E 03 41 > 01 00 ...+.........A.. > [0256] 30 13 06 0A 2B 06 01 02 01 02 02 > 01 10 01 41 05 0...+.........A. > [0272] 00 CC 99 CA 6D 30 13 06 > 0A 2B 06 01 02 01 02 02 ....m0...+...... > [0288] 01 10 02 41 05 > 29 FF EF EF 0C 30 0F 06 0A 2B 06 ...A.)....0...+. > [0304] 01 02 > 01 02 02 01 10 03 41 01 00 30 12 06 0A 2B ........A..0...+ > [0320] 06 01 02 01 02 02 01 11 01 41 04 01 31 42 C7 30 > .........A..1B.0 > [0336] 12 06 0A 2B 06 01 02 01 02 02 01 11 02 41 > 04 74 ...+.........A.t > [0352] 76 9E 10 30 0F 06 0A 2B 06 01 02 > 01 02 02 01 11 v..0...+........ > [0368] 03 41 01 00 30 0F 06 0A > 2B 06 01 02 01 02 02 01 .A..0...+....... > [0384] 13 01 41 01 00 > 30 0F 06 0A 2B 06 01 02 01 02 02 ..A..0...+...... > [0400] 01 13 > 02 41 01 00 30 0F 06 0A 2B 06 01 02 01 02 ...A..0...+..... > [0416] 02 01 13 03 41 01 00 30 0F 06 0A 2B 06 01 02 01 > ....A..0...+.... > [0432] 02 02 01 14 01 41 01 00 30 0F 06 0A 2B 06 > 01 02 .....A..0...+... > [0448] 01 02 02 01 14 02 41 01 00 30 0F > 06 0A 2B 06 01 ......A..0...+.. > [0464] 02 01 02 02 01 14 03 41 > 01 00 30 0F 06 0A 2B 06 .......A..0...+. > [0480] 01 02 01 02 02 > 01 15 01 42 01 00 ........B.. > debug: [965] > Net::SNMP::PDU::_process_var_bind_list(): { 1.3.6.1.2.1.2.2.1.10.1 => > Counter: 3432630893 } > error: [1438] > Net::SNMP::Message::_process_integer32(): The Counter length is too > long (6 bytes) > error: [299] > Net::SNMP::MessageProcessing::prepare_data_elements(): The Counter > length is too long (6 bytes) > error: [398] > Net::SNMP::Dispatcher::_transport_response_received(): The Counter > length is too long (6 bytes) > debug: [517] > Net::SNMP::Dispatcher::_event_delete(): deleted [ARRAY(0xae2b370)], > list is now empty > debug: [239] Net::SNMP::Dispatcher::deregister(): > removed handler for descriptor [3] > error: [2363] > Net::SNMP::__ANON__(): The Counter length is too long (6 bytes)
Subject: SV: [rt.cpan.org #74944] Problem with 6 byte Counter32
Date: Thu, 16 Feb 2012 08:59:18 +0000
To: "bug-Net-SNMP [...] rt.cpan.org" <bug-Net-SNMP [...] rt.cpan.org>
From: Henrik Berg <henrik.berg [...] barret.se>
I have been using snmpwalk with -v2c and changing to SNMPv1 sadly didn't help. snmpwalk must just use the 4 least significant bytes when these problems occur. Since it's a counter I guess that works, but I won't ask you to write logic for invalid cases like these. I'll just contact the customer and ask them to fix it. Thanks for your time and for this fine module. -henrik
Not a Net::SNMP issue.