[ZBX-17382] SNMP Text values are shown as HEX (or dots) values when contains non-english characters (non ASCII7) Created: 2020 Feb 27 Updated: 2025 Mar 18 Resolved: 2024 Nov 07 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | None |
Fix Version/s: | 7.0.1rc1, 7.2.0alpha1 |
Type: | Problem report | Priority: | Trivial |
Reporter: | Pablo | Assignee: | Vladislavs Sokurenko |
Resolution: | Fixed | Votes: | 4 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
||||||||||||||||||||
Issue Links: |
|
||||||||||||||||||||
Team: | |||||||||||||||||||||
Sprint: | S2401-2, S24-W8/9, S24-W18/19, S24-W20/21, S24-W22/23 | ||||||||||||||||||||
Story Points: | 2 |
Description |
SNMP Text values are shown as HEXA values when contains non-english characters (non ASCII7 I suppose)
Steps to reproduce:
Result: Expected: In attachment image with configuration of item and error. More info in: |
Comments |
Comment by Pablo [ 2020 Feb 27 ] |
verified in version Zabbix 4.0.0rc1 but I suppose this applies to other versions too |
Comment by Oleksii Zagorskyi [ 2020 Feb 28 ] |
Did you try to run snmp_get for the OID? |
Comment by Oleksii Zagorskyi [ 2020 Mar 04 ] |
Closing because of missing response. |
Comment by Pablo [ 2020 Mar 05 ] |
Oleksii, I have no access to CLI on this server to test you request, but in attachment I added an example from iReasoning MIB Browser (zabbix iReasoning.png) response. So please reopen issue. |
Comment by Oleksii Zagorskyi [ 2020 Mar 06 ] |
In the string "Pulse cualquier bot..n para comenzar" those two dots in word "bot..n" represents two HEX bytes: C3B3, which represents "ó" in UTF8. The mentioned OID base is: # snmptranslate 1.3.6.1.2.1.43.16.5.1.2 Printer-MIB::prtConsoleDisplayBufferText It comes from "ietf/Printer-MIB" mib file, from extended set of MIBs. prtConsoleDisplayBufferText OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtConsoleDescriptionStringTC MAX-ACCESS read-write STATUS current DESCRIPTION "The content of a line in the logical display buffer of the operator's console of the printer. When a write operation occurs, normally a critical message, to one of the LineText strings, the agent should make that line displayable if a physical display is present. Writing a zero length string clears the line. It is an implementation- specific matter as to whether the agent allows a line to be overwritten before it has been cleared. Printer generated strings shall be in the localization specified by prtConsoleLocalization.Management Application generated strings should be localized by the Management Application." ::= { prtConsoleDisplayBufferEntry 2 } PrtConsoleDescriptionStringTC ::= TEXTUAL-CONVENTION -- This TC did not appear in RFC 1759. STATUS current DESCRIPTION "An object MUST use this TEXTUAL-CONVENTION when its 'charset' is controlled by the value of prtConsoleLocalization." SYNTAX OCTET STRING (SIZE(0..255)) For now it's enough information for me. I need more time to test that. |
Comment by Oleksii Zagorskyi [ 2020 Mar 07 ] |
There indeed an issue with UTF8 (or any not ASCII chars) in SNMP response. There are a lot of discussions around that.
# snmpget -V
NET-SNMP version: 5.7.3
# snmpget -v 2c -c public 127.0.0.1 SNMPv2-MIB::sysLocation.0
SNMPv2-MIB::sysLocation.0 = STRING: bot..n
v 5.8
root@it0:/zab/58/bin# ./snmpget -V
NET-SNMP version: 5.8
# ./snmpget -v 2c -c public 127.0.0.1 SNMPv2-MIB::sysLocation.0
SNMPv2-MIB::sysLocation.0 = STRING: botón
Note, in this example I defined sysLocation on my linux box as "botón" and additionally tested v5.8 snmpget, compiled from sources. Using v 5.7 library in my zabbix, I collect value with dots, as "bot..n", which is the same as in command line tool output, which is expected. The only question why in your case you collect HEX values in zabbix. Here is copy-paste from corresponding MIBs (SNMPv2-MIB, SNMPv2-TC) : sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "The physical location of this node (e.g., 'telephone closet, 3rd floor'). If the location is unknown, the value is the zero-length string." ::= { system 6 } DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Represents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length." SYNTAX OCTET STRING (SIZE (0..255)) I'll try to find out how to test it also with, say, pure "OCTET STRING" to get HEX in zabbix as well. |
Comment by Oleksii Zagorskyi [ 2020 Mar 07 ] |
Just a note. # snmpget -v 2c -c public 127.0.0.1 SNMPv2-MIB::sysLocation.0 -d Sending 43 bytes to UDP: [127.0.0.1]:161->[0.0.0.0]:0 0000: 30 29 02 01 01 04 06 70 75 62 6C 69 63 A0 1C 02 0).....public... 0016: 04 5F 46 4A 7B 02 01 00 02 01 00 30 0E 30 0C 06 ._FJ{......0.0.. 0032: 08 2B 06 01 02 01 01 06 00 05 00 .+......... Received 49 byte packet from UDP: [127.0.0.1]:161->[0.0.0.0]:53815 0000: 30 2F 02 01 01 04 06 70 75 62 6C 69 63 A2 22 02 0/.....public.". 0016: 04 5F 46 4A 7B 02 01 00 02 01 00 30 14 30 12 06 ._FJ{......0.0.. 0032: 08 2B 06 01 02 01 01 06 00 04 06 62 6F 74 C3 B3 .+.........bot.. 0048: 6E n SNMPv2-MIB::sysLocation.0 = STRING: bot..n |
Comment by Pablo [ 2020 Mar 07 ] |
In my case I got this value from a Lexmark MS812, but other printers seems to be same problem. In this post you can see this case on Brother 8085DN printer, so I suppose is not exclusive from my model:
In this case, problem seems to be "ç" when translated: 53 75 62 73 74 2E 20 50 65 B5 61 73 20 55 6E 69 64 2E 20 43 69 6C 69 6E 64 72 6F to Subst. Peças Unid. Cilindro |
Comment by Artem Isaenko [ 2023 Sep 28 ] |
Guys i have same problem, And more i can convert it to utf-8, but have same result. So i was try push value to array, but data is bad too. |
Comment by Andrey Bitnyy [ 2023 Sep 28 ] |
The problem on Zabbix 6.4 remains |
Comment by Vladislavs Sokurenko [ 2023 Sep 29 ] |
Please also see |
Comment by Vladislavs Sokurenko [ 2024 Apr 15 ] |
Does new preprocessing option UTF-8 from hex-STRING help with the issue ? |
Comment by Vladislavs Sokurenko [ 2024 Apr 24 ] |
Fixed in pull request feature/ZBX-17382-6.5 |
Comment by Vladislavs Sokurenko [ 2024 Apr 30 ] |
Fixed in pull request feature/ZBX-17382-6.5 |
Comment by Vladislavs Sokurenko [ 2024 Jun 06 ] |
Fixed in:
|
Comment by Marina Generalova [ 2024 Nov 07 ] |
Documentation updated. Added a note about installing MIB files to: |