This isn't an "issue", per se - not actually causing a problem that I've seen...more of a small inconsistency with expectations / standards.
When looking at decoded packets in Wireshark sent from the library, it provides the following warnings (depending on BER protocol preferences in Wireshark):
[Expert Info (Warning/Malformed): Value is encoded with too many bytes(9 leading zero or one bits), hf_abbr: snmp.version]
[Expert Info (Warning/Malformed): Value is encoded with too many bytes(9 leading zero or one bits), hf_abbr: snmp.error_status]
[Expert Info (Warning/Malformed): Value is encoded with too many bytes(9 leading zero or one bits), hf_abbr: snmp.error_index]
Those three fields can (should?) be encoded as 1-byte ints, vs the 4 bytes used now - still the same ASN type 0x02, but with a length of 1.
I have a local branch of the library running on an ESP32, being hammered by Observium, having the change to make those respond with 1 byte, and all looks good.
I'd be happy to do a PR to integrate that change if interested.
This isn't an "issue", per se - not actually causing a problem that I've seen...more of a small inconsistency with expectations / standards.
When looking at decoded packets in Wireshark sent from the library, it provides the following warnings (depending on BER protocol preferences in Wireshark):
Those three fields can (should?) be encoded as 1-byte ints, vs the 4 bytes used now - still the same ASN type 0x02, but with a length of 1.
I have a local branch of the library running on an ESP32, being hammered by Observium, having the change to make those respond with 1 byte, and all looks good.
I'd be happy to do a PR to integrate that change if interested.