[BUG] SNMP v1 walk can fail in different ways about easysnmp HOT 13 OPEN

@Guens thanks for providing the sample code. I'll have to give it a try here sometime soon. In the meantime time can you downgrade EasySNMP to version 2.5 for me? I want to see if it is an existing issue. Or if we introduced it in 2.6.

This problem also occurs in 0.2.5, but with a different signal received :

retry_no_such=False : no such name error encountered

Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

from easysnmp.

@Guens thanks for providing the sample code. I'll have to give it a try here sometime soon. In the meantime time can you downgrade EasySNMP to version 2.5 for me? I want to see if it is an existing issue. Or if we introduced it in 2.6.

from easysnmp.

I'm able to replicate the bug with just easysnmp.snmp_walk(oids=".1.3.6.1", version=1, retry_no_such=...)

I also see that EasySNMP is not following expected behavior. This occurred as I tried to use the OID provided in the original example (which appears to be a vendor-specific MIB). snmpwalk -v1 generates the following packets:

Client                                                Server
  1 -- [get-next-request 1.3.6.1.4.1.30512.2.12.1.5] -->
   <-- [get-response 1.3.6.1.6.3.1.1.6.1.0] ----------- 2
  3 -- [get-request 1.3.6.1.4.1.30512.2.12.1.5] ------->
   <-- [get-response 1.3.6.1.4.1.30512.2.12.1.5] ------ 4 

No error is raised (return value 0)

Network traffic from easysnmp.snmp_walk(oids=".1.3.6.1.4.1.30512.2.12.1.5", version=1) only consists of packets 1 and 2. Packet 3 is never sent, so we're short-circuiting the exchange. An empty list is returned though. So it seems that there's another bug here that needs to be addressed as well.

from easysnmp.

I've pushed branch 162-retry-no-such-doublefree which should fix the underlying issue. Problem is that now the macOS builds fail because of a struct definition. If you're using Linux you can pull this branch locally and compile to test/verify the fix.

from easysnmp.

Please try using the test branch and see if it resolves all your use-cases.

from easysnmp.

Please try using the test branch and see if it resolves all your use-cases.

@kamakazikamikaze Finally had some time to test this. I used the sample script provided by @Guens. Interestingly enough, I get no errors if I request "iso.3.6.1.2.1.25.1.1.0" (The standard Linux uptime OID if my memory is correct).

But, if I do the one you tested @kamakazikamikaze ".1.3.6.1.4.1.30512.2.12.1.5" I do get an error:

I have python 3.10.4 installed on Ubuntu 22.04
I'll try here shortly with the fix on the test branch.

Update:

Results with the test branch changes using OID ".1.3.6.1.4.1.30512.2.12.1.5":

from easysnmp.

Please try using the test branch and see if it resolves all your use-cases.

@kamakazikamikaze Finally had some time to test this. I used the sample script provided by @Guens. Interestingly enough, I get no errors if I request "iso.3.6.1.2.1.25.1.1.0" (The standard Linux uptime OID if my memory is correct).

But, if I do the one you tested @kamakazikamikaze ".1.3.6.1.4.1.30512.2.12.1.5" I do get an error:

I have python 3.10.4 installed on Ubuntu 22.04

I'll try here shortly with the fix on the test branch.

Update:

Results with the test branch changes using OID ".1.3.6.1.4.1.30512.2.12.1.5":

I read my emails and almost didn't see that you updated your comment. Am I correct in my understanding that this appears to fix the issue as per your "update" section?

from easysnmp.

Please try using the test branch and see if it resolves all your use-cases.

@kamakazikamikaze Finally had some time to test this. I used the sample script provided by @Guens. Interestingly enough, I get no errors if I request "iso.3.6.1.2.1.25.1.1.0" (The standard Linux uptime OID if my memory is correct).
But, if I do the one you tested @kamakazikamikaze ".1.3.6.1.4.1.30512.2.12.1.5" I do get an error:

I have python 3.10.4 installed on Ubuntu 22.04
I'll try here shortly with the fix on the test branch.
Update:
Results with the test branch changes using OID ".1.3.6.1.4.1.30512.2.12.1.5":

I read my emails and almost didn't see that you updated your comment. Am I correct in my understanding that this appears to fix the issue as per your "update" section?

Yes, sorry for that confusion. The fix seems to fix the issue per my "update" section.

from easysnmp.

Yes, sorry for that confusion. The fix seems to fix the issue per my "update" section.

It wasn't confusing. I just wanted to double-check.

As for the issue itself, my understanding is that @Guens expects either retry_no_such=False or retry_no_such=True to successfully return data like the snmpwalk command. retry_no_such=False raises the exception correctly as intended by the original author teams. retry_no_such=True should be the solution to their current problem. I'll leave the issue open until they are able to test and verify that everything works as intended.

from easysnmp.

@kamakazikamikaze your understanding is correct :-)
I expect data returned, whatever retry_no_such value.

I have tried your latest branch test, with this code :

import easysnmp

try:
    easysnmp.snmp_walk(oids=".1.3.6.1.4.1.30512.2.12.1.5", hostname="10.174.202.133", version=1, retry_no_such=False)
except Exception as _e:
    print(f"retry_no_such=False : {_e}")

a = easysnmp.snmp_walk(oids=".1.3.6.1.4.1.30512.2.12.1.5", hostname="10.174.202.133", version=1, retry_no_such=True)
print(a)

and here is the result :

retry_no_such=False : no such name error encountered
[<SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.1', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.2', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.3', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.4', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.5', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.6', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.7', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.8', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.9', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.10', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.11', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.12', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.13', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.14', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.15', oid_index='', snmp_type='INTEGER')>, <SNMPVariable value='0' (oid='enterprises.30512.2.12.1.5.16', oid_index='', snmp_type='INTEGER')>]

Your modification fixes the problem when retry_no_such=True ; oids are well returned.

But when retry_no_such=False a NOSUCH exception is still raised, despite oid .1.3.6.1.4.1.30512.2.12.1.5 do exist.

What do you think about it ?

from easysnmp.

Your modification fixes the problem when retry_no_such=True ; oids are well returned.

But when retry_no_such=False a NOSUCH exception is still raised, despite oid .1.3.6.1.4.1.30512.2.12.1.5 do exist.

What do you think about it ?

@Guens I think you should do a packet capture and open the result in Wireshark. What I think you'll find is that .1.3.6.1.4.1.30512.2.12.1.5.17 gets requested and the SNMP Agent responds with a noSuch* error. If so, an exception is raised because technically the agent returns an error status. This would be expected handling of the error when retry_no_such=False and version=1 and not a bug even though we have received data from the MIB tree(s).

Having said that, I do question whether or not this method of handling is the right way to do things. It would make more sense to only raise the exception if the error status is returned for the first packet we send. The snmpwalk binary doesn't raise an error in this specific case and neither should we. I may need some time or input from users to decide on the right path forward.

from easysnmp.

@kamakazikamikaze you are right, the walk ask for a get-next-request after .1.3.6.1.4.1.30512.2.12.1.5.16 and a noSuchName is returned :

CLI snmpwalk has the same exchanged packets, except it does not raise an error at the end.

That's why I think your proposal really make sense : raising an exception only if the error status is returned for the first packet we send.

from easysnmp.

@kamakazikamikaze you are right, the walk ask for a get-next-request after .1.3.6.1.4.1.30512.2.12.1.5.16 and a noSuchName is returned :

You'll probably find that SNMPv2 won't raise this error. But seeing that your other issues mention SNMPv3, I'm going to assume that your target device only supports v1. As such, I recommend setting retry_no_such=True for now to get what you need.

CLI snmpwalk has the same exchanged packets, except it does not raise an error at the end.

That's why I think your proposal really make sense : raising an exception only if the error status is returned for the first packet we send.

It may make sense but it may be a long time before I'm ready to approve a change like that. I don't know who else, if anyone, uses EasySNMP with v1 that would be impacted by the change. There is probably also a good reason why the original developers decided to make it a flag option instead of implementing it the way I described. I'll need some time to research before I come to any conclusion.

from easysnmp.