It is becoming frequent that a dialog like this happens: Me: SNMP_GET ifName.1 Agent: noSuchName (error-index: 2) Me: "2", okay. Let me remove the second OID and try again. SNMP_GET ifName.1 Agent: noSuchName (error-index: 2) Me: "2", okay. Let me remove the second OID and try again. SNMP_GET ifName.1 Agent: noSuchName (error-index: 2) Me: "2", okay. Let me remove the second OID and try again. SNMP_GET ifName.1 ... Here, "error-index" should be "1"; however, the agent is improperly returning "2". The library should be able to handle such situations and not be tricked into looping indefinitely. I have updated the "snmp_fix_pdu" function to fail if (in addition to the current failure conditions) the error-index value is greater than the number of variables in the PDU. This patch is for 5.4.2.1 Note that it is EXACTLY the same as the patch for 5.4.1. Reproducible: Always Steps to Reproduce: 1. To a sysEdge agent: snmpget -v1 -cXXX Y.Y.Y.Y ifName.100 (assuming ifName.100 does not exist). 2. Infinite loop occurs; a "tcpdump port 162" will show an infinite series of retries, as sysEdge reports "noSuchName(2)" AND "error-index = 2"; however, ifName.100 is the OID at index "1"; so the library attempts to remove the OID at index 2 (there is none) and resends the packet (in this case, in its entirety). Actual Results: Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: ... ad infinitum Expected Results: Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: I've submitted a patch to net-snmp and I am using it in a production system for a customer; everything works properly (the same problem is evident when using PHP's "snmpget", and this addresses that, too). My patch is available from the link provided for additional information above.
Created attachment 179891 [details, diff] The patch for the problem This patch is exactly the same for 5.4.1. Note: the directory applies to: snmplib
Doug, thank you for report. But I can't reproduce your problem with 5.4.2.1: camobap-unstable log # snmpget -v1 -ctest 127.0.0.1 ifName.4 IF-MIB::ifName.4 = STRING: irlan0 camobap-unstable log # snmpget -v1 -ctest 127.0.0.1 ifName.5 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: IF-MIB::ifName.5 So agent just reports error as it should... What do I miss?
(In reply to comment #2) > Doug, thank you for report. But I can't reproduce your problem with 5.4.2.1: > > camobap-unstable log # snmpget -v1 -ctest 127.0.0.1 ifName.4 > IF-MIB::ifName.4 = STRING: irlan0 > camobap-unstable log # snmpget -v1 -ctest 127.0.0.1 ifName.5 > Error in packet > Reason: (noSuchName) There is no such variable name in this MIB. > Failed object: IF-MIB::ifName.5 > > So agent just reports error as it should... What do I miss? > Thank you for your interest; your test is good... HOWEVER, you will need a *buggy* client that returns an error-index of "2" instead of "1". You can hack net-snmp (on another box) to do this if you need to test.
(In reply to comment #3) > HOWEVER, you will need a *buggy* client that returns an error-index of "2" > instead of "1". You can hack net-snmp (on another box) to do this if you need > to test. I' lost. In comment #0 you wrote ''the agent is improperly returning "2".'' which has reverse sense. Could you explain another time what issue is and how to trigger it? The more details the better since I really don't understand what this issue affects.
(In reply to comment #4) > (In reply to comment #3) > > HOWEVER, you will need a *buggy* client that returns an error-index of "2" > > instead of "1". You can hack net-snmp (on another box) to do this if you need > > to test. > > I' lost. In comment #0 you wrote ''the agent is improperly returning "2".'' > which has reverse sense. Could you explain another time what issue is and how > to trigger it? The more details the better since I really don't understand what > this issue affects. > Ah, I see your source of confusion. The net-snmp *agent* works perfectly fine. However, the net-snmp *client* has issues when *another* agent returns improper "error-index" values. So, your first step is to hunt down a buggy agent that will lie to you about its "error-index" value. I have found SysEDGE agents to do this on some versions (I can't name any at this time--they are at a customer location). Or, you can hack a net-snmp agent to return an incorrect error-index. Then, using the net-snmp client (in testing), you can try to ask for something that doesn't exist; you'll get an error-number of "2" (noSuchName), and then an error-index of say, "2" or "3" or "4". If that error-index is not "1", then the net-snmp client will enter into an infinite retransmit loop that is not so pretty.
Can you please test with 5.7.2_rc3 and reopen if it's still an issue?
