Bug 256531 – net-analyzer/net-snmp-5.4.1 (and 5.4.2.1): Infinite retry loop when agent replies with invalid error-index on non-set request

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Doug 2009-01-27 16:53:28 UTC]

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.

[Comment 1 Doug 2009-01-27 17:03:37 UTC]

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

[Comment 2 Peter Volkov (RETIRED) 2009-03-02 11:04:17 UTC]

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?

[Comment 3 Doug 2009-03-02 14:14:52 UTC]

(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.

[Comment 4 Peter Volkov (RETIRED) 2009-03-02 15:43:36 UTC]

(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.

[Comment 5 Doug 2009-03-02 15:55:01 UTC]

(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.

[Comment 6 Diego Elio Pettenò (RETIRED) 2012-10-04 16:03:09 UTC]

Can you please test with 5.7.2_rc3 and reopen if it's still an issue?