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

[Mike C. F. <mcf...@ro...>]

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>

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/