[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: |