openSUSE appliance

It could done in scope of ZBXNEXT-1444. For better performance it should be supported natively.

I'm seeing the same sort of problem here (running 2.2.0).
When I query an SNMP OID that should contain an IP address, the device in question reports back this HEX-string:

"0A 85 98 FF" Which translates to "10 133 152 255" (add the dots and you have an IP address).

It would be nice if Zabbix could translate this numeric hex into a human-readable IP address.

The same problem with Juniper.
Oid jnxBgpM2PeerRemoteAddr (and others) returns Hex-STRING: D5 85 A0 B1 which means IP-address 213.133.160.177 (in this example).
With Zabbix 2.2.2 I have to create external script for discover BGP table and convert such hex values to IP-addresses. It's working but not very convenient and effective.
The same conversion could be done for IPv6 addresses, and those hex-strings are too long for store as numeric values.

The same problem with some HP printers when retrieving the consumables (e.g. toners) using OID 1.3.6.1.2.1.43.11.1.1.6.1. The names of that consumables will be shown as hex string. This is annoying especially when using discovery rules since the items got that hex string names.

You can reproduce that with Net-SNMPs snmpwalk as shown here for a HP printer model LaserJet 500 color M551:
> snmpwalk -v2c -c foo ps27 1.3.6.1.2.1.43.11.1.1.6.1.1
SNMPv2-SMI::mib-2.43.11.1.1.6.1.1 = Hex-STRING: 42 6C 61 63 6B 20 43 61 72 74 72 69 64 67 65 20
35 30 37 58 20 48 50 20 43 45 34 30 30 58 00

For snmpwalk a work around will help. Just add option -Oa:
> snmpwalk -v2c -Oa -c foo ps27 1.3.6.1.2.1.43.11.1.1.6.1.1
SNMPv2-SMI::mib-2.43.11.1.1.6.1.1 = STRING: "Black Cartridge 507X HP CE400X."

Is issue closed?

For my opinion it is not closed yet. Did Zabbix provide any update, I didn't see yet? I'm currently running Zabbix 3.0.2.

I stay in contact with HP. But I'm afraid that HP wont fix the firmware of their printers. HP says that some SNMP agents interpret the data as hex decimal value while the others interpret the data as octet string. If your SNMP agent does interpret the data as hex decimal value, you are not a lucky guy.

The problem occurs with some HP printers, because they sent a trailing zero byte. See my last post. You can force the Net-SNMP command line tools, to interpret the data as octet string by using the -Oa option. Again see my last post. Since Zabbix using the Net-SNMP library as well, it must be a simple way, to tell Zabbix to force the Net-SNMP library to interpret the data as octet string instead of as hex decimal value.

I actually ran into the opposite issue with hrPrinterDetectedErrorState. It ends up being interpreted as string, and thus is incompatible with the numeric type it needs to be.

Thus ut requires the -Ox option to work properly.

$ snmpwalk -c public -v 1 segotppl001 hrPrinterDetectedErrorState
HOST-RESOURCES-MIB::hrPrinterDetectedErrorState.1 = STRING: "\""

$ snmpwalk -c public -v 1 -Ox segotppl001 hrPrinterDetectedErrorState
HOST-RESOURCES-MIB::hrPrinterDetectedErrorState.1 = Hex-STRING: 22

I upgraded from CentOS 6 to 7 and am running into this issue. snmpwalk on CentOS 7 returns Hex-STRING for printer supplies OID 1.3.6.1.2.1.43.11.1.1.6 where as CentOS 6 returned STRING. It would be great to have this option in Zabbix. It looks like my only option right now is to write a discovery script.

Solving this issue would make Zabbix to a even better software. I use the following perl script as work around:

use strict;

# Configuration variables
my $snmpwalk_command = "snmpwalk -On -Oa";
my $consumable_names_oid = ".1.3.6.1.2.1.43.11.1.1.6.1";
my $usage = "Error! Need at least 3 arguments: SNMP version, SNMP community and host name or ip address. \n E. g.: $0 2c public printer1";

# Get command line arguments.
my $snmpversion = shift || die($usage);
my $snmpcommunity = shift || die($usage);
my $hostoraddress = shift || die($usage);

# Print beginning of the JSON data string.
print "{\n";
print "\t\"data\":[\n\n";

my $first_element = 1;

foreach my $output (`$snmpwalk_command -v$snmpversion -c $snmpcommunity $hostoraddress $consumable_names_oid 2>&1`) {
        if ($output =~ /^$consumable_names_oid\.([0-9]+) = STRING: \"(.*)\"$/) {
                print "\t,\n" if not $first_element;
                $first_element = 0;

                print "\t{\n";
                print "\t\t\"{#SNMPINDEX}\":\"$1\",\n";
                print "\t\t\"{#SNMPVALUE}\":\"$2\"\n";
                print "\t}\n";
        }
}

# Print end of the JSON data string.
print "\n\t]\n";
print "}\n";

So the only option to convert hex-string values to string is using scripts?
We used snmp discovery for supermicro motherboards, but in the latest versions of their boards they began to use the hex-string for description of sensors and our discovery template stopped working.

I have the same issue like Alexander G..
Is it possible to add the -Oa extension native somewhere?

Hi Alexander, Thanks for the script, although I still have some troubles getting the actual values. Would you be so kind to share your template?

Here comes the template:

SNMPv2c Printers use external script.xml

You can also call the script from command line like this: ./discover_printer_consumables.pl 2c public printer

Where 2c stands for SNMP Version 2c, public is the SNMP community string and printer is the ip address or name of the printer.

Please make sure, that you copied the script in to the right location as cofigured in zabbix_server.conf by the parameter ExternalScripts (e. g. /usr/lib/zabbix/externalscripts).

Hope that helps!

Hi Alexander, Thanks for your help! It works great! (Zabbix 4.0)

I hope this bug will be fixed until we celebrate 10 years... really ashaming.
Item preprocessing is not acceptable solution because it oftenly used with LLD, so it is hard to tell value will be string or hex-string.

One moar 10 years old FR... Hope never dies.

updated

It's not a bug, i't's a feature request. As such it's open for sponsored development, send an email to [email protected] if you'd like to have this implemented.

That being said, in Zabbix 4.2 it might be possible to use a pre-processing javascript to handle this conversion (although I haven't looked into that topic yet). Any confirmation from the Zabbix devs that this would be possible or not?

That being said, in Zabbix 4.2 it might be possible to use a pre-processing javascript to handle this conversion (although I haven't looked into that topic yet). Any confirmation from the Zabbix devs that this would be possible or not?

Yes, it's possible, please try something like this:

var out = "";

for (var i = 0, nums = value.split(" "); i < nums.length; i++) {
	out += String.fromCharCode(parseInt(nums[i], 16));
}

return out;

Vladislav, thank you for you script, but in my case it working only in test mode, I added it to preprocessing and got error - "Invalid discovery rule value:"

Also I found somewhere that use {} inside function Zabbix doesn't support.

Any ideas?

It should work the same way as during the test, can you please show the test output ?

discovery{#SERIALRWNAME},1.3.6.1.4.1.3212.7.1.3.4.1.1.1.2

Discovered name is - "22 53 6C 6F 74 20 54 68 72 65 00"

When I run through the script I have expected name as -  "Slot Thre

But today when I tested discovery I got new error - Invalid discovery rule value: cannot find pair with name "{#IFNAME}" when I remove preprocessing script discovering works.

Vladislavs'  scripts works fine for a single hex value. If you use that in an LLD, it'll only replace the first value found.

I wrote this script to correct that:

var out = "";
var regex = /{#SNMPVALUE}":"([0-9 A-F a-f ]*) "}/;
var m;

do {
  m = regex.exec(value)
  if (m) {
    var str = "";
    for (var i = 0, nums = m[1].split(" "); i < nums.length; i++) {
      str += String.fromCharCode(parseInt(nums[i], 16));
    }
    value = value.replace(m[1], str);
  }
} while (m);

return (value);

You'll need to fiddle with the regex, watch for whitespaces etc.

Hello everyone, and thanks to the unsubscribed above. There is a little problem with 0x00 symbol in the SNMP answer, so there is a  little modified JS for converts HEX to String, for Zabbix data collectors prototypes and items.

For discovery group:

var regex = /"{#SNMPVALUE}":"([0-9 A-F ]*) "}/;
var m;
do {
  m = regex.exec(value)
  if (m) {
    var str = '';
    hex = m[1];
	hex = hex.replace(/ /g,'');
    for (var n = 0; n < hex.length; n += 2) {
        if (hex.substr(n, 2) != '00'){
			str += String.fromCharCode(parseInt(hex.substr(n, 2), 16));
		}
    }
    value = value.replace(m[1], str);
  }
} while (m);
return (value);

And for prototypes of items:

 var str1 = value;
  var hex  = str1.toString();  
  if (! hex.match(/\b[0-9A-F ]{6}\b/gi))
  {
    return str1;
  }  else  {
      
      hex = hex.replace(/ /g,"");
      var str = '';
      for (var n = 0; n < hex.length; n += 2) {
        str += String.fromCharCode(parseInt(hex.substr(n, 2), 16));
      }
      return str;
  }

@Eugene , thanks!

Sorry for the noobish question, but where exactly do you put those snippets in (i'm using 5.0 lts)

Is it in one place for all (where?), or somewhere more global?

For the most part, this should be solved by ZBXNEXT-8645, which introduces the new preprocessing rule UTF-8 from Hex-STRING. The only bit from the original request that is not covered is octal conversion. Is the octal conversion real deal these days?

Please also see if ZBX-17382 helps with original issue

The original issue from the report is completed under ZBXNEXT-8645.
Please see UTF-8 from Hex-STRING