Asynchronous getNext errors out when going out of table
I am using one of the examples for GetNext
operation for an SNMPWalk of the tree. I am using the asynchronous variant to collect the OIDs -
# GETNEXT Command Generator
from pysnmp.entity.rfc3413.oneliner import cmdgen
from pysnmp.proto import rfc1902
# ( ( authData, transportTarget, varNames ), ... )
targets = (
# 1-st target (SNMPv1)
( cmdgen.CommunityData('test-agent-1', 'public'),
cmdgen.UdpTransportTarget(('localhost', 161)),
(rfc1902.ObjectName((1,3,6,1,2,1)), rfc1902.ObjectName((1,3,6,1,3,1)))),
# 2-nd target (SNMPv2c)
( cmdgen.CommunityData('test-agent-2', 'public', 1),
cmdgen.UdpTransportTarget(('localhost', 161)),
(rfc1902.ObjectName((1,3,6,1,2,1,2)),) ),
)
def cbFun(
sendRequestHandle, errorIndication, errorStatus, errorIndex,
varBindTable, (varBindHead, authData, transportTarget)
):
if errorIndication:
print 'SNMP engine error', errorIndication
return 1
if errorStatus:
print 'SNMP error %s at %s' % (errorStatus, errorIndex)
return 1
varBindTableRow = varBindTable[-1]
for idx in range(len(varBindTableRow)):
name, val = varBindTableRow[idx]
if val is not None and varBindHead[idx].isPrefixOf(name):
# still in table
break
else:
print 'went out of table at %s' % (name, )
return
for varBindRow in varBindTable:
for oid, val in varBindRow:
if val is None:
print oid.prettyPrint()
else:
print '%s = %s' % (oid.prettyPrint(), val.prettyPrint())
return 1 # continue table retrieval
cmdGen = cmdgen.CommandGenerator()
for authData, transportTarget, varNames in targets:
cmdGen.asyncNextCmd(
authData, transportTarget, varNames,
# User-space callback function and its context
(cbFun, (varNames, authData, transportTarget))
)
cmdGen.snmpEngine.transportDispatcher.runDispatcher()
I get the OIDs I need; however when it goes out the table and returns from cbFun, the Dispatcher in the last line throws an error, which I am not able to resolve, the output looks something like -
... (some 1.3.6.1.2.1.* stuff)
1.3.6.1.2.1.2.2.1.22.1 = 0.0
1.3.6.1.2.1.2.2.1.22.2 = 0.0
1.3.6.1.2.1.2.2.1.22.3 = 0.0
went out of table at (1, 3, 6, 1, 2, 1, 3, 1, 1, 1, 2, 1, 212, 201, 49, 186)
Traceback (most recent call last):
File "asyncsnmpwalk.py", line 55, in <module>
cmdGen.snmpEngine.transportDispatcher.runDispatcher()
File "/var/lib/python-support/python2.5/pysnmp/v4/carrier/asynsock/dispatch.py", line 61, in runDispatcher
self.handleTimerTick(time())
File "/var/lib/python-support/python2.5/pysnmp/v4/carrier/base.py", line 81, in handleTimerTick
self.__timerCbFun(timeNow)
File "/var/lib/python-support/python2.5/pysnmp/v4/entity/engine.py", line 60, in __receiveTimerTickCbFun
self.msgAndPduDsp.receiveTimerTick(self, timeNow)
File "/var/lib/python-support/python2.5/pysnmp/v4/proto/rfc3412.py", line 491, in receiveTimerTick
self.__cacheExpire(snmpEngine, self.__expireRequest)
File "/var/lib/python-support/python2.5/pysnmp/v4/proto/rfc3412.py", line 56, in __cacheExpire
if cbFun(snmpEngine, cachedParams):
File "/var/lib/python-support/python2.5/pysnmp/v4/proto/rfc3412.py", line 486, in __expireRequest
cbCtx
File "/var/lib/python-support/python2.5/pysnmp/v4/entity/rfc3413/cmdgen.py", line 77, in processResponsePdu
(self.processResponsePdu, (cbFun, cbCtx))
File "/var/lib/python-support/python2.5/pysnmp/v4/entity/rfc3413/cmdgen.py", line 164, in _sendPdu
(processResponsePdu, float(timeout)/100 + time.time(), cbCtx)
File "/var/lib/python-support/python2.5/pysnmp/v4/proto/rfc3412.py", line 161, in sendPdu
sendPduHandle
File "/var/lib/python-support/python2.5/pysnmp/v4/proto/mpmod/rfc2576.py", line 89, in prepareOutgoingMessage
scopedPDU
File "/var/lib/python-support/python2.5/pysnmp/v4/proto/secmod/rfc2576.py", line 78, in genera开发者_运维技巧teRequestMsg
errorIndication = 'unknownCommunityName'
pysnmp.proto.error.StatusInformation: {'errorIndication': 'unknownCommunityName'}
changing CommunityData string did the trick (I don't know why)
BEFORE
cmdgen.CommunityData('test-agent-1', 'public'),
AFTER
cmdgen.CommunityData('test-agent', 'public'),
That seems to happen on request retry. So it may not be relevant to going out of table.
I'd suggest upgrading your pysnmp installation from CVS at SourceForge in hope that it's a already fixed bug. Otherwise, please report to pysnmp-users@lists.sourceforge.net
精彩评论