SNMP engine ID OID returns truncated values
7 posts · Closed
I am using the remote SNMP functionality to query SNMP object values of our switches (Juniper Networks EX, various models). This works well, except for a certain SNMP object, the engine ID (OID: 1.3.6.1.6.3.10.2.1.1.0). When querying, I receive the set value for the switch, but it is always missing the last two characters, regardless of the length:
I do not observe this behaviour with any other SNMP objects I query.
When using snmpget, the full value is displayed:
net:~> snmpget -v 2c -c bx_read 172.16.1.15 1.3.6.1.6.3.10.2.1.1.0 -O a iso.3.6.1.6.3.10.2.1.1.0 = STRING: "... L.BX117665" net:~> snmpget -v 2c -c bx_read 172.16.1.16 1.3.6.1.6.3.10.2.1.1.0 -O a iso.3.6.1.6.3.10.2.1.1.0 = STRING: "... L.BX0"
Is this a known issue, or perhaps a configuration error?
Thanks in advance for any assistance.
Regards,
Luca
It is likely that this byte sequence (EngineID) is being misinterpreted as a UTF-8 string when it is actually a hexadecimal sequence. We will investigate this further and provide an update here shortly.
In SNMP, the OctetString data type can be used to carry both ASCII and UTF-8 strings, as well as binary data.
We've added a new setting that allows you to specify the string format in cases where the data is incorrectly detected as UTF-8. Please download the latest build, and select either ASCII or HEX for the EngineID to ensure it displays correctly:
Thanks for the quick update. I did tests with both ASCII and HEX option, but the issue still persists.
ASCII:
HEX:
With both options, the last two characters are still missing.
You can also see this when comparing the HEX-Values:
net:~> snmpget -v 2c -c bx_read 172.16.1.15 1.3.6.1.6.3.10.2.1.1.0 iso.3.6.1.6.3.10.2.1.1.0 = Hex-STRING: 80 00 0A 4C 04 42 58 31 31 37 36 36 35
172.16.1.15
WVZ-A-blau-15
1002433732 (116d 0h 32m 17s)
Juniper Networks, Inc. ex4100-48mp Ethernet Switch, kernel JUNOS 22.4R3-S3.3, Build date: 2024-07-04 09:31:38 UTC Copyright (c) 1996-2024 Juniper Networks, Inc.
IT
MS1103--WVZ-B-blau
JUNOS Base OS Software Suite [22.4R3-S3.3]
EF BF BD 00 0A 4C 04 42 58 31 31 37 36
Thank you! We have successfully reproduced this issue, and it should now be fully resolved.
Please download the latest build and let us know how it works for you.
It is indeed fully resolved, and the whole value is displayed. Thank you very much for the quick fix.
Just out of curiosity, could you say what caused the issue?
Likewise, thank you for providing the clear and detailed information that allowed us to reproduce and fix the bug.
The issue was in the conversion of binary data to a UTF-8 string that caused some of the binary data to become malformed.
We have updated the code to correct the problem, and are very glad to hear that everything works well for you now.