No way to convert Counter64 buffer

[kaytrance]

ok, I am struggling to find any reliable way to convert Counter64 type to string or number.
As mentioned here for that type of data this library utilizes Node's Buffer and returns a Buffer that I suppose to convert later by myself.

My problem is that example above produces zeros all the time even when I can see that there's no empty buffer returned by this library.

Metric that I try to parse is ifHCInOctets (its oid is 1.3.6.1.2.1.31.1.1.1.6). By using snmpget on this oid I can confirm that there's a value returned (not equal to 0). Using this package I can see that <Buffer 01 c9 5d> (which is something) which (according to straight snmpgeting the value) should give a value of 22860 (according to just snmpget for my given interface). This counter is frozen now because no traffic is flowing, but it is not 0 for sure.

I have tried int64-buffer package that always gives me 0, I have tried node-cint64 which gave me not 0, but some incorrect value either way.

So is it a bug? Or maybe any live example that shows correct value transformation can be given here?

Much appreciated! Thank you!

[stephenwvickers]

Hi @kaytrance

I've only ever used buffers for 64bit integers. The moment you convert it to a number you have issues with JavaScript not supporting full 64bit integers, that is all 64bits.

I can see the same issue as you with int64-buffer:

> new Uint64BE(new Buffer([0x01, 0xc9, 0x5d]))
Int64 { buffer: [ 0, 0, 0, 0, 0, 0, 0, 0 ], offset: 0 }

I think this might be because the buffer is not big enough, this seemed to work:

> new Uint64LE(new Buffer([0xc9, 0x5d, 0, 0, 0, 0, 0, 0, 0])).toString()
'24009'

I had to reverse the order of the bytes, use the little-endian integer, and pad it it to ensure the buffer had 8 bytes.

Also, I had to drop the leading 0x01 from the original buffer read from the network, and I think probably relates the ASN.1 encoding in relation to the integer being signed.

Hope that helps :(

Steve