Pysnmp：SnmpWalk从下一个oid开始

Question

I want to start walking from the oid that i provided to NextCmd and not from the oid after that. Here is my code:

import datetime, time
from pysnmp.entity.rfc3413.oneliner import cmdgen
from pysnmp.smi import builder, view, error

def __cbFun_Walk(sendRequestHandle, errorIndication, errorStatus, errorIndex, varBindTable, cbCtx):
    (authData, transportTarget) = cbCtx
    for varBindTableRow in varBindTable:
        for oid, val in varBindTableRow:
            print 'OID: ' + str(oid) + ' VAL: ' + str(val.prettyPrint())
    return False

cmdGen = cmdgen.AsynCommandGenerator()
cmdGen.asyncNextCmd(
        cmdgen.CommunityData('public', mpModel=1),
        cmdgen.UdpTransportTarget(('192.168.0.101', 161)),
        (str('1.3.6.1.2.1.4.1.0'),),
        (__cbFun_Walk, (cmdgen.CommunityData('public', mpModel=1), cmdgen.UdpTransportTarget(('192.168.0.101', 161)))))
cmdGen.snmpEngine.transportDispatcher.runDispatcher() 

This code prints "OID: 1.3.6.1.2.1.4.2.0 VAL: 64".
As you can see it gives me the value of the oid that comes after the oid that i provided.
I would like to get the value of the oid "1.3.6.1.2.1.4.1.0" using NextCmd.

Answer 1

What you observe is exactly how GETNEXT/GETBULK SNMP commands should work. If you want to fetch one specific OID, you should use the GET command along with the GETNEXT iteration.

In other words, you could have two-phase script - first you run asyncGetCmd() against the OID you want to read. Then you fire up asyncNextCmd() against the same OID. For both steps you can use nearly identical code from your example. Ultimately, you fetch both initial OID and all subsequent ones.

Alternatively, a hackerish approach, would be to artificially "decrement" the OID you aim at so that the "next" OID to the "decremented" one would become precisely the OID you want to read. And here you have two options: either you can strip the last sub-OID (eg you end up with 1.3.6.1.2.1.4.1) or decrement the rightmost greater-then-zero sub-OID (eg 1.3.6.1.2.1.4.0.0).

The problem here is that generally you can't be absolutely sure that no OIDs fall in-between. Then you may end-up getting the wrong OID in response. However stripping the last '0' is probably save (since it's a scalar).

As a side note: consider trying out the latest high-level APU , it might be a little easier to deal with.