Re: [pysnmp-users] Bug in 3.3.4 snmpwalk.py?

[Ilya E. <il...@gl...>]

A list for users of pure-Python SNMP framework <pysnmp-users.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pysnmp-users>,
	<mailto:pys...@li...?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pysnmp-users>

Yeah, that first GET request has been added to make snmpwalk.py behaving
closer to Net-SNMP's snmpwalk. This has been implemented to do GET
unconditionally and not to ignore [possible] errors so that's buggy.

I've just re-worked the snmpwalk*.py code to fire GET only when
instructed from command line (-Ci) e.g. in the same way as it's done in
Net-SNMP. Please, try it out (CVS rev 1.3.2.19) and let me know in case of
any probs:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pysnmp/pysnmp/examples/snmpwalk.py?only_with_tag=version-3-branch

Regarding 2.0 compatibility -- could you please send me either exceptions
or entire code so I'd try to debug it.

Thanks,
ilya

> We've been encountering a lot of out-of-order problems with our use of 
> PySNMP 2.0.5, so we were planning to move to 3.3.4 today (which has, at 
> least in the examples, explicit checks for out-of-order messages), or 
> rewrite the 2.0.5 code to avoid the OOR problems. 
> 
> However, on installing 3.3.4, something seems wonky (that's a technical 
> term ;) ).  I ran a few tests to see that the system was installed 
> correctly and got some surprising results.  For instance, querying a 
> DOCSIS Cable Modem Termination System for the IP addresses of the 
> connected modems:
> 
> 08:41:49 mcfletch@cmon:~/pysnmp-3.3.4/examples $ python snmpwalk.py 
> 172.16.0.1 public .1.3.6.1.2.1.10.127.1.3.3.1.3
> Traceback (most recent call last):
>   File "snmpwalk.py", line 132, in ?
>     raise str(rsp['pdu'].values()[0]['error_status']) + ' at '\
> ErrorStatus: 3 ((badValue) The value given has the wrong type or length) 
> at .1.3.6.1.2.1.10.127.1.3.3.1.3
> 08:43:29 mcfletch@cmon:~/pysnmp-3.3.4/examples $ python snmpwalk.py 
> 172.16.0.1 public .1.3.6.1.2.1.10.127.1.3.3.1.3.1
> .1.3.6.1.2.1.10.127.1.3.3.1.3.1  --->  '172.16.9.125'
> 08:43:33 mcfletch@cmon:~/pysnmp-3.3.4/examples $ python snmpwalk.py 
> 172.16.0.1 public .1.3.6.1.2.1.10.127.1.3.3.1.3.2
> .1.3.6.1.2.1.10.127.1.3.3.1.3.2  --->  '172.16.6.38'
> 08:46:06 mcfletch@cmon:~/pysnmp-3.3.4/examples $ python snmpwalk.py 
> 172.16.0.1 public .1.3.6.1.2.1.10.127.1.3.3.1.3.3
> .1.3.6.1.2.1.10.127.1.3.3.1.3.3  --->  '172.16.2.229'
> 08:46:11 mcfletch@cmon:~/pysnmp-3.3.4/examples $
> 
> That is, snmpwalk seems to choke on the first response to the walk (the 
> one that's doing a GET instead of a GETNext (which has changed between 
> these two versions)), but is perfectly happy to get the sub-elements 
> manually (with the GET I would assume).  The same error is returned for 
> doing an snmpget.py request on the table root.
> 
> Other tables do appear to be traversed correctly...
> 
> 09:03:33 mcfletch@cmon:~/pysnmp-3.3.4/examples $ python snmpwalk.py 
> 172.16.0.1 public .1.3.6.1.2.1.10.127.1.3.3
> .1.3.6.1.2.1.10.127.1.3.3.1.2.1  --->  '\x00\xe0o\x05@Q'
> .1.3.6.1.2.1.10.127.1.3.3.1.2.2  --->  '\x00\xe0o\x04\x08\xaf'
> .1.3.6.1.2.1.10.127.1.3.3.1.2.3  --->  '\x00\xe0o\x05\xc0\x7f'
> .1.3.6.1.2.1.10.127.1.3.3.1.2.4  --->  '\x00\xe0o\x05@\xd3'
> ...
> 
> Now, I'll wind up rewriting the snmpwalk stuff anyway to fit into a 
> library module for our system, but I'm wondering whether that first 
> "get" request is really supposed to be there, and if so, what it's 
> supposed to be doing.  If it's not really necessary I may just wrap a 
> try:except: around it to catch this case, but I'd like to know why it's 
> there before I start ignoring it.
> 
> BTW, we weren't able to get our PySNMP 2.x code to work with the 3.x 
> compatability layer.  Exceptions deep in the bowels of PySNMP kept 
> popping up.
> 
> Ideas welcome,
> Mike
> 
> _______________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://members.rogers.com/mcfletch/