lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Am 17.02.2010 13:50, schrieb Yuri Kozlov:
2010/2/17 hleuwer<>:
Am 16.02.2010 12:43, schrieb Yuri Kozlov:


Linux 32-bit, luasnmp 1.0.5

yuray@yuray:~$ lua -l snmp -i
Lua 5.1.3 Â Copyright (C) 1994-2008, PUC-Rio

=snmp.newvar("", 33)

IF-MIB::ifHCOutOctets.51 = Counter64: 33

=snmp.newvar("", 34)

IF-MIB::ifHCOutOctets.51 = Counter64: 4294967296

Very strange result. :(
How to fix this?

This is a bug in src/nm_util.c during the conversion of the value into
net-snmp internal Counter64 representation - patch attached.

Works better, but:

max value
return snmp.newvar("", 18446744073709551615)
IF-MIB::ifHCOutOctets.51 = Counter64: 0

return snmp.newvar("", 1844674407370955161)
IF-MIB::ifHCOutOctets.51 = Counter64: 1844674407370955264

is not equal. For counter type this is unacceptable.

You are right. Lua is not able to handle 64 bit precision with it's built-in
type double. I should have thought of this. Sorry.

> a=snmp.newvar("", 18446744073709551615)
> table.foreach(a, print)
value   1.844674407371e+19
type    11

I have to solve this issue from ground up for all 64 bit types of SNMP.
In the meanwhile you may want to use the function snmp.sprintvar2 to convert
64 bit values. This yields inaccurate, but at least more consistent results
(see below).
You can also change the __tostring metamethod for varbinds (see snmp.lua) to
use this function:
__vbindmetatable = {
  __tostring = function(vb) return sprintvar2(vb) end,

> return snmp.newvar("", 18446744073709551615)
ifHCOutOctets.51 (Counter64) = 1.844674407371e+19
> return snmp.newvar("", 1844674407370955161)
ifHCOutOctets.51 (Counter64) = 1.844674407371e+18

Other stuff should (hopefully) work - I haven't spent much time in testing this
temporary workaround.
> a = snmp.newvar("", 18446744073709551615)
> b = snmp.newvar("", 1844674407370955161)
> = a==b
> b = snmp.newvar("", 18446744073709551614)
> = a==b

Considering the rounding error the latter comparison result may be acceptable.

Of course, 64 bit values read from real sessions will also loose precision while being passed through the Lua universe.

I have to think about and find time to work on a good final solution. This will
most probably result in a new version of luasnmp.

Any ideas of course welcome :-).

Thanks for the hints.