Inconsistency in variable binding response value - Windows SNMP agent

Question

Have an observation the way SNMP get-response values are populated for Microsoft snmp agent and an agent which is running in the switch.

I am trying to query some object id's. I am sending a request for all the object id's in a single request pdu message.

Behavior in Windows SNMP agent:

In the requested object ids, if any object id is not present in the agent, then the entire response message is set with the errorcode "noSuchObject" and all the requested object id values are returning with null even if there are some valid object id's present in the agent.

Whereas we tried getting the same list of oids from an agent running in a cisco switch, there the error code is set for the specific variable binding and it is returning values for all the other oids which are present.

Please Wireshark log (windows agent and cisco switch)refer the attached wireshark snapshot for the windows agent and cisco agent.

RFC https://tools.ietf.org/html/rfc3416#section-4.2.1 mentions in the particular scenario response variable binding’s value field shall to set to “noSuchInstance” Additional Information:
Microsoft OS: Windows server 2016

Questions:

1. Why this behavior of Microsoft?

2. Is there any Microsoft forum to get further support for this?

3. Any existing solution or workaround for this problem?

Answer 1

As Lex indicated in his/her comment, the SNMP ecosystem enjoys remarkable noncompliance across implementations despite a wonderfully precise "standard" (via RFCs). When writing an SNMP agent or manager you have to be aware of all manner of in-practice deviations from the expected behaviour. Unfortunately you seem to have found one of them.

You can try pushing Microsoft to fix this particular bug, but in my view the odds of success are very low, and even then you'd still have to support the older implementation.

Your workaround is to make requests for individual objects, perhaps up-front but at the very least when you get a "noSuchObject" response with null varbinds when you think this response is suspicious. Your application can do this automatically, entering a sort of "fallback mode" to attempt to detect which object triggered the bug and to get the values of the objects that still exist.

It'll obviously be slower than a single Get for all interesting objects, but the upside is that now you'll actually get the data you need.

Bonus points if a standard object like sysDescr happens to reliably identify this particular buggy agent, so you can restrict your fallback mode to that specific case.