SNMP GetResponse with non-minimal INTEGER request-id causes exception (extra 0xFF sign byte)

[KarloX2]

Hello,

we are seeing an exception in SharpSNMP when receiving an SNMP GetResponse whose request-id INTEGER is BER-encoded with a non-minimal length.

Example from a real capture:

Request Id in my own GetRequest (correctly created with sharpsnmplib): 02 04 FB 6A 65 17

Request Id in the received GetResponse (causes the exception): 02 05 FF FB 6A 65 17

The numeric value of the request-id is identical, but the response includes an extra leading 0xFF sign-extension byte, making the INTEGER non-canonical. This violates BER minimal encoding rules, but the value itself is unambiguous and accepted by other SNMP implementations. I have no control over the agent software, so I'm unable to change the behavior on their side.

Questions:

• Is this strict behavior intentional?
• Would you consider accepting non-minimal INTEGER encodings for request-id (possibly behind a tolerance/compatibility option)?
• If not, is there a recommended workaround at the application level?

Thanks for your guidance.

[lextm]

You might want to read #474 and #178 to get some basic ideas. Since the request IDs in response messages mirror the ones sent from your code, you can limit the range of such IDs proactively to avoid bugs on the agent side.

This library is aiming to just meet the standards, and not providing too many workarounds for faulty implementations.