Wrong HEX-String to decimal conversion

[BXN]

Hello everyone!

I have a new installation of Cacti on 2 systems:

OS: Windows 7 Pro 64bit
Webserver: Apache 2.4.3 Win32
Cacti: 0.8.8a (cmd.php)
MySQL: 5.0.10
PHP: 5.4.7
RRDTool: 1.4.5 Win32
Net-SNMP: 5.6.1.1

OS: Debian 6.0.7 i386
Webserver: Apache 2.2.16
Cacti: 0.8.8a (cmd.php)
MySQL: 5.1.66
PHP: 5.3.3
RRDTool: 1.4.3
Net-SNMP: 5.4.3

And everything works fine except one counter which I’m reading using SNMP (Indexed). It’s hex-string counter of transmitted Bytes and Cacti (or RRD, I don’t know) is messing up conversion to decimal.

I performed a little experiment. I configured Cacti with this OID as Counter and Derive and I downloaded a 349 MB file. Before and after I used SNMPWALK to verify is it monitored device a source of problem, but not.

SNMPWALK returns value 00 00 00 00 24 5C 4C 11 and 00 00 00 00 3B 66 8D 03, so the difference is 00 00 00 00 17 0A 40 F2, which converted to decimal gives 386 547 954 B = 368 MB transmitted.
In the same time Cacti returned value of 4,83 GB

What can I do?

[BXN]

I found something interesting!

HEX-String from snmpwalk = 00 00 00 00 06 D2 E3 D6 is written to MySQL DB as 00:00:00:00:06:D2:E3:D6 (= 114 484 182 B). To RRD file goes value of 415 841 005 782 B, which in HEX-String is 60D20E30D6.
Cacti is inserting 0 in place of : or space.
06:D2:E3:D6 => 060D20E30D6

It happends on both systems. They use cmd.php (soon maybe I'll migrate to Spine).

How can I fix that?

[paulgevers]

I found something interesting!

HEX-String from snmpwalk = 00 00 00 00 06 D2 E3 D6 is written to MySQL DB as 00:00:00:00:06:D2:E3:D6 (= 114 484 182 B). To RRD file goes value of 415 841 005 782 B, which in HEX-String is 60D20E30D6.
Cacti is inserting 0 in place of : or space.
06:D2:E3:D6 => 060D20E30D6

It happends on both systems. They use cmd.php (soon maybe I'll migrate to Spine).

How can I fix that?

Sounds like a bug. Have you looked at the cacti bug tracker and considered reporting it there?

[BSOD2600]

What OID is in question? a standard MIB or something custom from a vendor? Typically interface OIDs used a counter, not hex string...

[BXN]

Sounds like a bug. Have you looked at the cacti bug tracker and considered reporting it there?

Not yet since I'm new with Cacti and I didn't feel competent enough to do so...

What OID is in question? a standard MIB or something custom from a vendor? Typically interface OIDs used a counter, not hex string...

It's a custom vendor OID (Alcatel-Lucent), but I did a little experiment with Windows OIDs and the effect was the same - there were additional 0 in this hex-string.

[UPDATE]
I compiled Spine 0.8.8a on Debian machine and after modifying lib/functions.php (is_hexadecimal function) by adding:

Code: Select all

$hexstr = str_replace(' ', ':', $hexstr);
$hexstr = str_replace('-', ':', $hexstr);

(since Spine treats hex-string with spaces as NOT hex-string - as darckos mentioned in "Problems with HEX Values from SAN Switch") conversion works as it should with this Windows OID I used in experiment (1.3.6.1.2.1.55.1.5.1.8.x)

cmd.php still fails so it looks like a bug...

Code: Select all

poller output: 00:21:5D:9B:13:A9
expected rrd input: 143 304 364 969 (I get it now with moded Spine)
rrd input: 9 295 067 743 334 569
hex value of rrd input: 21 0 5D 0 9B 0 13 0 A9

[UPDATE 2]
On Windows Spine 0.8.8a (Win32) with modification mentioned above, everything works fine. Reporting 0.8.8a cmd.php bug right away.

[gandalf]

Issues reagarding specific hex conversions are know, please search bug database before adding a new one. You may add your findings to those bugs, then. Code contributions are welcomed
R.