Is there a way to identify what type of return an SNMP response is?

[baltimorestrings]

E.G when polling with snmptools get, I can see if a return is an Integer, Counter32, HexStr, OctetStr, etc.

Is this possible with the Gufo SNMP returns? I just see a Tuple, but curious if it's possible to see the type from MIB definitions (?).

[dvolodin7]

Actually, the data type is included with the value as part of the BER encoding. Gufo SNMP simplifies the process by converting these values to the appropriate Python types, resulting in a clean and practical API. Another reason for this design choice is performance, as Gufo SNMP was created to serve as the primary SNMP engine for a Network Operations Center (NOC), where some installations are very SNMP-intensive.

That said, I think an additional API that returns type wrappers could be developed. This would be useful both for debugging and for correctly implementing the SNMP SET operation.

[baltimorestrings]

Thank you for responding, and yes - I did start taking a look at the rust and noticed that you do process the type and have all the different types in ber/t_*.rs each with their own ToPython. I actually hacked in creating a PyTuple to just see how that would work, and was considering making a Python snmp variable object (like easysnmp returns, here.

I was considering PRing this, but I do know that doing that would make this significantly slower - as your lib is super fast, just returning the str/int/python type necessary, so I understand that might be the preferred behavior. I wonder if it wouldn't slow it down too much to have a slower path present that returns that?

The only reason it matters is telling the difference between octet strings and strings, since we poll across a few vendors that all do very slightly different patterns, which we handle by examining the type section of the SNMP response.

Thanks again for a great lib, we've been testing it pretty intensely as we start to switch towards it, and it's the first Python SNMP lib that can actually compete with the C snmptools bindings, which is very helpful (snmptools has to be compiled with --enable-reentrant in order to not crash when being used in a heavily threaded environment, which creates all sorts of complications).

I'll start reviewing and see if we actually do need this type field, or if it's possible to check the data itself.

[dvolodin7]

Thank you for responding.

To add from our side, the NOC supports more than 100 vendors. We've moved the vendor-specific components into integration adapters, making variable type analysis almost unnecessary. As a result, MIBs are not used directly to poll equipment.

That said, I'll consider developing a separate API with relaxed requirements regarding performance and garbage collection pressure.

[baltimorestrings]

That's a really smart setup. I've actually been looking at throwing an adaptor over this so we can just use your lib and tag on the types as needed until we can refactor the client code to not need it (we run a plugin architecture, so individual plugins are designed by individuals, hence us trying to start at 1:1 parity, then move forward once we're on gufo_snmp), which'll probably result in something similar. For now, since I have to compile this locally anyways (see the mac install issue ), I've just been modifying the to_pythons to return a simple tuple with the varbind type character (..., "a"), which works perfectly.

Thanks again for the response, I see your point in that the type really does reduce to python types straightforwardly, this discussion item can be considered resolved.