cmdGen.getCmd with multiple oid returns failure for all oids even if only one fails

[turboc1208]

Using code similar to this example, when I passed in 4 oid's for my ink jet's color cartridges, I got "no such object currently exists at this oid" for each object. All error status were 0 so cmdGen.getCmd thought it returned successfully. Only one of the OID's was incorrect but all 4 returned the same message.

from pysnmp.entity.rfc3413.oneliner import cmdgen

cmdGen = cmdgen.CommandGenerator()

errorIndication, errorStatus, errorIndex, varBinds = cmdGen.getCmd(
    cmdgen.CommunityData('public'),
    cmdgen.UdpTransportTarget(('localhost', 161)),
    '1.3.6.1.2.1.1.1.0',
    '1.3.6.1.2.1.1.6.0'
)

# Check for errors and print out results
if errorIndication:
    print(errorIndication)
else:
    if errorStatus:
        print('%s at %s' % (
            errorStatus.prettyPrint(),
            errorIndex and varBinds[int(errorIndex)-1] or '?'
            )
        )
    else:
        for name, val in varBinds:
            print('%s = %s' % (name.prettyPrint(), val.prettyPrint()))

Desired results would be to return the correct value for each oid and return the error message only on the one that actually failed.

[etingof]

You are using SNMP v2c protocol, it does not indicate nonexistent OIDs with errorStatus. Instead it uses special sentinel value in oid-value pairs (pysnmp prints out that value as an error message). That hopefully explains why errorStatus is noError. You can switch to SNMP v1 and see the difference.

Now the question is why your printer does not return the OID-value pairs you expect it to return. Besides probably useless hint of replacing localhost with the IP address of your printer, I'd also check with printer's documentation to make sure it supports SNMP v2c, uses public community and has all that enabled.

Try sending your printer a single OID -- some embedded SNMP implementations are known to behave strangely in a non-straightforward settings.

Since I imagine your code is slightly different from the paste above, I'd advise you to enable pysnmp debugging in your script and take a look at the SNMP messages going towards your printer and back. May be you'd spot some suspicious things there. You are welcome to paste them in here for me to take a look as well.

Finally, I'd suggest you switching over to the latest release pysnmp version and base your code on its hlapi interface.

[turboc1208]

Thanks for the quick feedback. What's so strange is it's just the magenta cartridge. The others work great. I don't believe it is a problem with pysnmp, I actually found a unresolved notice out on one of the linux boards where someone was having the exact same problem with magenta. I guess printers don't like magenta or something.
My concern with pysnmp was that if there is one oid in the list that has a problem, it reports the problem for all the items, even though the others would work fine if the problem oid is taken out.
I was using the hlapi interface, but it seemed more complex and confusing at the time. I'll go back and look at it.
Thanks again.

[etingof]

Failing all OIDs in presence of a single failed OID may represent some sort of compromise in embedded SNMP implementation. My theory is based on the design of SNMP v1 which has a single index (e.g. error-index) for pointing out failing OID. If more than one OID fail, SNMP v1 has no way to communicate that back to client. When implementing SNMP v2c on top of existing v1 implementation, they may have decided to leave SNMP v1 logic in place just replacing error-index pointer with noSuchObject sentinel.

But that's just a theory, no hard evidence... ;-)

The hlapi thing was designed to remediate pysnmp usage complications. That gives me hope that it should be easer for you to accommodate. Here's a quick link to respective documentation page.