[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: PNG File Notepad++ conversion.png     PNG File ZabbixSnmpErrorWithSpanishCharacters.png     PNG File image-2023-09-28-17-43-38-667.png     PNG File image-2023-09-28-17-44-08-058.png     PNG File image-2023-09-28-17-45-28-691.png     PNG File image-2023-09-28-17-45-48-605.png     PNG File zabbix iReasoning.png    
Issue Links:
Duplicate
is duplicated by ZBX-23801 Unexpected results with snmp Hex-Stri... Closed
is duplicated by ZBX-24177 SNMPAgent item return HEXString or St... Closed
Sub-task
part of ZBXNEXT-505 support hex and octal conversion to t... Closed
Team: Team A
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)
Example:
SNMP Message gathered from printer "imprimiendo página 1/1..."  (contains "á") is shown as HEXA values. 

 

Steps to reproduce:

  1. Create new SNMP item type TEXT in host for, lets say, OID 1.3.6.1.2.1.43.16.5.1.2.1.1
  2. get value that has non english character
  3. See value on Latest data for host

Result:
When text have a non english character is shown as HEXA values instead of TEXT 

Expected:
ASCII Text should be shown always as text (NO HEXA values) 

In attachment image with configuration of item and error. 

More info in:
https://www.zabbix.com/forum/zabbix-help/393854-printer-s-display-message-status-using-snmp-sometimes-shows-message-as-hexa-values <- in English
https://www.zabbix.com/forum/em-portugues-y-en-espanol/35348-compartilhando-template-impressora-brother?p=395136#post395136 <- in Spanish



 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?
Try it also with different output modes, defined by -O parameter.

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.
In second phrase/screenshot I could see the same character.

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.
Related lines, just in case:

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.
This could be somehow related to ZBX-8338.

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.
There could be also different behavior for different net-snmp versions, as described here - https://sourceforge.net/p/net-snmp/bugs/2815/
This regression introduced in v .5.7
I can confirm this behavior for v5.7 and as Ia see (in changelog "- [BUG 2815]: Display UTF-8 characters again" ) it's fixed in v 5.8
v 5.7

# 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.
Maybe the reason because sysLocation actually also applies " DISPLAY-HINT "255a"", which is mentioned in the net-snmp's but 2815 (see link below), while your prtConsoleDisplayBufferText is treated only as "OCTET STRING".
These nesting properties are visible in iRreasoning MIB broser, which you used.

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.
After that we will be able to decide what to do.

Comment by Oleksii Zagorskyi [ 2020 Mar 07 ]

Just a note.
Option -d for snmpget allows to see those "C3 B3" HEX codes in response.
This is the only way I discovered to see actual bytes:

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

https://www.zabbix.com/forum/em-portugues-y-en-espanol/35348-compartilhando-template-impressora-brother?p=395136#post395136

 

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,
In hex-code with cirrylic. On test i have a good value, but when items start work i see in database strange values with dots.

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 ZBXNEXT-8645

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
Improved get[oid] and walk[oid] to display UTF-8 text instead of hex if MIB files are not installed, however it is currently unknown if such fix is necessary or problem is usually solved by just installing MIB files, moving to need info

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:

Generated at Thu Jun 26 10:36:34 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.