Skip Menu |

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

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

People
Owner: dtown [...] cpan.org
Requestors: samuel.mutel [...] free.fr
Cc:
AdminCc:

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



Subject: Unable to get_table with special character
Hello, The command below hangs indefinitely : my $run_path_table = '1.3.6.1.2.1.25.4.2.1.4'; $session->get_table(Baseoid => $run_path_table); On the snmpd server side, I have : ... Mar 9 15:52:51 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.5302 Mar 9 15:52:51 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.5303 Mar 9 15:52:51 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.5304 Mar 9 15:52:51 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.5305 Mar 9 15:52:51 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.5306 Mar 9 15:52:51 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.5307 So I get information of hrSWRunPath table with id 5308 : HOST-RESOURCES-MIB::hrSWRunPath.5308 = STRING: "postgres: opennms opennms 127.0.0.1(55549) idle" When I stop the program (opennms) this process is not in the hrSWRunPath table and the script runs successfully. Regards, Samuel Mutel.
What do you mean by a special character? How does that affect the get_table() method? You will need to provide some debug output. Add the option "-debug => 0xff" to the session() constructor and update this ticket with the output. The get_table() method should either timeout if there is not response from the host or report an error if the table being queried has some sort of loop.
From: samuel.mutel [...] free.fr
I think it's due to a problem with special character but it's a supposition. Here is the last 20 lines in debug mode : debug: [1498] Net::SNMP::Message::_process_octet_string(): not translating OCTET STRING, all octets are allowed in a DisplayString debug: [976] Net::SNMP::PDU::_process_var_bind_list(): { 1.3.6.1.2.1.25.4.2.1.4.22541 => OCTET STRING: /usr/sbin/httpd } debug: [516] Net::SNMP::Dispatcher::_event_delete(): deleted [ARRAY(0x95aa9fc)], list is now empty debug: [238] Net::SNMP::Dispatcher::deregister(): removed handler for descriptor [3] debug: [439] Net::SNMP::Dispatcher::_event_insert(): created new head and tail [ARRAY(0x95ab1f4)] debug: [687] Net::SNMP::Message::send(): transport address 10.250.40.38:161 debug: [2050] Net::SNMP::Message::_buffer_dump(): 139 bytes [0000] 30 81 88 02 01 03 30 10 02 04 61 CA 76 E1 02 02 0.....0...a.v... [0016] 05 C0 04 01 07 02 01 03 04 39 30 37 04 0D 80 00 .........907.... [0032] 1F 88 80 D1 0A 5B 47 42 9C 72 4B 02 01 02 02 03 .....[GB.rK..... [0048] 12 AB 10 04 06 6B 65 79 72 75 73 04 0C 21 9B D8 .....superv..!.. [0064] 22 39 C5 E7 C0 C4 AB 40 F1 04 08 FA 07 39 5B 44 "9.....@.....9[D [0080] A6 06 FB 04 36 B1 3E 3A CD 6E 25 CC 97 62 16 C8 ....6.>:.n%..b.. [0096] 72 0E 7B 38 DB 8B 4D 89 EF E9 B4 41 87 ED EE 0C r.{8..M....A.... [0112] 50 34 68 F0 D5 DF 24 2F C9 6F 97 C2 A1 F3 6F 88 P4h...$/.o....o. [0128] A0 5D 09 FD E4 FD C9 52 F7 E8 99 .].....R... debug: [199] Net::SNMP::Dispatcher::register(): added handler for descriptor [3] debug: [461] Net::SNMP::Dispatcher::_event_insert(): modified tail [ARRAY(0x94f5778)] debug: [534] Net::SNMP::Dispatcher::_event_delete(): deleted [ARRAY(0x95ab1f4)], defined new head [ARRAY(0x94f5778)] debug: [595] Net::SNMP::Dispatcher::_event_handle(): event [ARRAY(0x94f5778)], timeout = 59.9999
According to the debug, the Net::SNMP module sent a message (I assume a get-bulk-request) for the next entry in the table and is waiting 59.9999 seconds for the response. The problem appears to be at the agent. I assume your "timeout" value is set to 60 seconds. This would explain the apparent "hang" of the script if the agent does not respond. -David On Thu Mar 11 03:31:27 2010, smutel wrote: Show quoted text
> I think it's due to a problem with special character but it's a
supposition. Show quoted text
> > Here is the last 20 lines in debug mode : > > debug: [1498] Net::SNMP::Message::_process_octet_string(): not > translating OCTET STRING, all octets are allowed in a DisplayString > debug: [976] Net::SNMP::PDU::_process_var_bind_list(): { > 1.3.6.1.2.1.25.4.2.1.4.22541 => OCTET STRING: /usr/sbin/httpd } > debug: [516] Net::SNMP::Dispatcher::_event_delete(): deleted > [ARRAY(0x95aa9fc)], list is now empty > debug: [238] Net::SNMP::Dispatcher::deregister(): removed handler for > descriptor [3] > debug: [439] Net::SNMP::Dispatcher::_event_insert(): created new head > and tail [ARRAY(0x95ab1f4)] > debug: [687] Net::SNMP::Message::send(): transport address
10.250.40.38:161 Show quoted text
> debug: [2050] Net::SNMP::Message::_buffer_dump(): 139 bytes > [0000] 30 81 88 02 01 03 30 10 02 04 61 CA 76 E1 02 02 > 0.....0...a.v... > [0016] 05 C0 04 01 07 02 01 03 04 39 30 37 04 0D 80 00 > .........907.... > [0032] 1F 88 80 D1 0A 5B 47 42 9C 72 4B 02 01 02 02 03 > .....[GB.rK..... > [0048] 12 AB 10 04 06 6B 65 79 72 75 73 04 0C 21 9B D8 > .....superv..!.. > [0064] 22 39 C5 E7 C0 C4 AB 40 F1 04 08 FA 07 39 5B 44 > "9.....@.....9[D > [0080] A6 06 FB 04 36 B1 3E 3A CD 6E 25 CC 97 62 16 C8 > ....6.>:.n%..b.. > [0096] 72 0E 7B 38 DB 8B 4D 89 EF E9 B4 41 87 ED EE 0C > r.{8..M....A.... > [0112] 50 34 68 F0 D5 DF 24 2F C9 6F 97 C2 A1 F3 6F 88 > P4h...$/.o....o. > [0128] A0 5D 09 FD E4 FD C9 52 F7 E8 99 .].....R... > debug: [199] Net::SNMP::Dispatcher::register(): added handler for > descriptor [3] > debug: [461] Net::SNMP::Dispatcher::_event_insert(): modified tail > [ARRAY(0x94f5778)] > debug: [534] Net::SNMP::Dispatcher::_event_delete(): deleted > [ARRAY(0x95ab1f4)], defined new head [ARRAY(0x94f5778)] > debug: [595] Net::SNMP::Dispatcher::_event_handle(): event > [ARRAY(0x94f5778)], timeout = 59.9999 >
From: samuel.mutel [...] free.fr
It is very strange because when I use snmpwalk on the same OID, I don't have timeout. Here is the time to execute snmpwalk on oid .1.3.6.1.2.1.25.4.2.1.4 real 0m0.218s user 0m0.059s sys 0m0.006s Here is the message on snmp server side : Mar 11 14:53:07 onms-dev last message repeated 14 times Mar 11 14:55:27 onms-dev snmpd[3277]: Connection from UDP: [x.x.x.x]:42425 Mar 11 14:55:27 onms-dev snmpd[3277]: Received SNMP packet(s) from UDP: [x.x.x.x]:42425 Mar 11 14:55:27 onms-dev snmpd[3277]: Connection from UDP: [x.x.x.x]:42425 Here is the message on snmp server side with Net:SNMP get_table .1.3.6.1.2.1.25.4.2.1.4 : Mar 11 14:55:28 onms-dev last message repeated 139 times Mar 11 14:57:25 onms-dev snmpd[3277]: Connection from UDP: [x.x.x.x]:49695 Mar 11 14:57:25 onms-dev snmpd[3277]: Received SNMP packet(s) from UDP: [x.x.x.x]:49695 Mar 11 14:57:25 onms-dev snmpd[3277]: Connection from UDP: [x.x.x.x]:49695 Mar 11 14:57:26 onms-dev last message repeated 4 times Mar 11 14:57:26 onms-dev snmpd[3277]: send response: Too long (plaintext scopedPDU header type 00: s/b 30) Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20270 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20392 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20872 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20873 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20874 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20875 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20876 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20877 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20878 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20879 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20881 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20882 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21009 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21010 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21011 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21012 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21013 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21014 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21015 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21694 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21698 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21699 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21723 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21726 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21779 Do you think it's
From: samuel.mutel [...] free.fr
It is very strange because when I use snmpwalk on the same OID, I don't have timeout. Here is the time to execute snmpwalk on oid .1.3.6.1.2.1.25.4.2.1.4 real 0m0.218s user 0m0.059s sys 0m0.006s Here is the message on snmp server side : Mar 11 14:53:07 onms-dev last message repeated 14 times Mar 11 14:55:27 onms-dev snmpd[3277]: Connection from UDP: [x.x.x.x]:42425 Mar 11 14:55:27 onms-dev snmpd[3277]: Received SNMP packet(s) from UDP: [x.x.x.x]:42425 Mar 11 14:55:27 onms-dev snmpd[3277]: Connection from UDP: [x.x.x.x]:42425 Here is the message on snmp server side with Net:SNMP get_table .1.3.6.1.2.1.25.4.2.1.4 : Mar 11 14:55:28 onms-dev last message repeated 139 times Mar 11 14:57:25 onms-dev snmpd[3277]: Connection from UDP: [x.x.x.x]:49695 Mar 11 14:57:25 onms-dev snmpd[3277]: Received SNMP packet(s) from UDP: [x.x.x.x]:49695 Mar 11 14:57:25 onms-dev snmpd[3277]: Connection from UDP: [x.x.x.x]:49695 Mar 11 14:57:26 onms-dev last message repeated 4 times Mar 11 14:57:26 onms-dev snmpd[3277]: send response: Too long (plaintext scopedPDU header type 00: s/b 30) Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20270 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20392 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20872 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20873 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20874 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20875 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20876 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20877 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20878 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20879 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20881 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.20882 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21009 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21010 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21011 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21012 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21013 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21014 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21015 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21694 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21698 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21699 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21723 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21726 Mar 11 14:57:26 onms-dev snmpd[3277]: -- HOST-RESOURCES-MIB::hrSWRunPath.21779 Do you think it's a bug in Net:SNMP agent or in your module ? Thanks for your help.
The Net::SNMP module uses get-bulk-requests by default to perform the get_table() action when using SNMPv3. And I have a feeling that the "snmpwalk" you are performing is using get-next-requests. Looking at the server log I see: Mar 11 14:57:26 onms-dev last message repeated 4 times Mar 11 14:57:26 onms-dev snmpd[3277]: send response: Too long (plaintext scopedPDU header type 00: s/b 30) My guess is that the server is generating a response to the get-bulk-requests that is "Too long" to send and the response is dropped causing the Net::SNMP module to wait for the timeout. You can force the Net::SNMP module to use get-next-requests by adding the option "-maxrepetitions => 1" to the get_table() call. The problem would be with the server and how the it builds the response. It should not build a response to a get-bulk-request so big that it cannot send it. -David Show quoted text
> Do you think it's a bug in Net:SNMP agent or in your module ? > Thanks for your help.
From: samuel.mutel [...] free.fr
Thank you for your help. Do you have an idea of the command line that I can use to reproduce this problem ? I try snmpbulkwalk but I don't have the same behaviour. Regards, Samuel Mutel. Le Jeu 11 Mar 2010 10:25:27, DTOWN a écrit : Show quoted text
> The Net::SNMP module uses get-bulk-requests by default to perform the > get_table() action when using SNMPv3. And I have a feeling that the > "snmpwalk" you are performing is using get-next-requests. > > Looking at the server log I see: > > Mar 11 14:57:26 onms-dev last message repeated 4 times > Mar 11 14:57:26 onms-dev snmpd[3277]: send response: Too long (plaintext > scopedPDU header type 00: s/b 30) > > My guess is that the server is generating a response to the > get-bulk-requests that is "Too long" to send and the response is dropped > causing the Net::SNMP module to wait for the timeout. > > You can force the Net::SNMP module to use get-next-requests by adding > the option "-maxrepetitions => 1" to the get_table() call. > > The problem would be with the server and how the it builds the response. > It should not build a response to a get-bulk-request so big that it > cannot send it. > > -David >
> > Do you think it's a bug in Net:SNMP agent or in your module ? > > Thanks for your help.
>
Try using the -Cr25 option. That is the default max-repetitions value for get_table(). snmpbulkwalk is an SNMP application that uses SNMP GETBULK requests to query a network entity efficiently for a tree of information. ... -Cr<NUM> Set the max-repetitions field in the GETBULK PDUs. This specifies the maximum number of iterations over the repeating variables. The default is 10. n Mon Mar 15 04:34:22 2010, smutel wrote: Show quoted text
> Thank you for your help. > Do you have an idea of the command line that I can use to reproduce this > problem ? > I try snmpbulkwalk but I don't have the same behaviour. > > Regards, > Samuel Mutel. > >
Issue appeared to be with the how the agent was (not) handling get-bulk-requests that resulted in a large response due to the setting of the max-repetitions value.