Need patch for Zabbix 1.1.6 to support Negative integers

[dan.searle]

I have multiple wireless boxes which can return signal strengths for radio links, using snmpwalk on the ralavent OID's I get values like:

INTEGER: -51

for the link strength OIDs. However, it seems Zabbix stable 1.1.6 can not handle signed integers, (or floats for that matter).

Someone must have a fix for this? I don't mind contributing to a patch if one of the developers can help point me in the right direction. I had a look at the source code myself but it's difficult to read or make sense of.

Looks like someone has tried to fix it before, but the snmp poller code seems to treat all integer types as unsigned for some reason. I tried to hack at it, but it wasn't playing.

Does the Beta 1.3 branch support signed integers and graphing them?

Dan...

[medic]

if you always get negative numbers, why don't multiply with -1 ?

[dan.searle]

I have tried this, i.e. adding a multiplier of (-1), but it does not work. You get a really big negative number stored rather than a really big positive number.

[Alexei]

Is your item defined as float?

[dan.searle]

I've tried defining the items as both float and integer, both options result in really big numbers being stored, as far as I can tell from the source code, all values are treated as unsigned. If you look at the snmp poller source for the zabbix_server daemon, all "INTEGER" types returned by SNMP are treated as unsigned 64 bit integers. I suspect that later on some other code is converting the 64bit unsigned int to a double. This is why it doesn't matter if I define the item as float or integer, the database always has massively large numbers stored instead of the negative values.

[Alexei]

You are absolutely right! Some works has to be done in order to make all components (server, graphs, etc) support negative numbers.

[James Wells]

As I recall, we store the data in the DB history tables as unsigned int for integers and doubles for floats. I suspect this is where the issue is happening.

[dan.searle]

The history table storage is indeed an issue which needs to be addressed, however, the zabbix_server source code for the SNMP poller also has issues with nagative integers. It appears that the SNMP poller handles all "INTEGER" types returned by SNMP clients as unsigned 64 bit integers, probably because of the issue with the history table only storing values as unsigned, however according to the SNMP specification, INTEGER and INTEGER32 types are 32 bit signed values, UNSIGNED32 and GAUGE32 are unsigned 32 bit integers...

4.6.1. Usage of Data Types

4.6.1.1. INTEGER, Integer32, Gauge32, and Unsigned32

The 32-bit integer data types INTEGER, Integer32, Gauge32, and
Unsigned32 are described in RFC 2578 Section 2 and further elaborated
in RFC 2578 Sections 7.1.1, 7.1.7, and 7.1.11. The following
guidelines apply when selecting one of these data types for an object
definition or a textual convention:

- For integer-valued enumerations:

- INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST
NOT be used.

Note that RFC 2578 recommends (but does not require) that integer-
valued enumerations start at 1 and be numbered contiguously. This
recommendation SHOULD be followed unless there is a valid reason to
do otherwise, e.g., to match values of external data or to indicate
special cases, and any such special-case usage SHOULD be clearly
documented. For an example, see the InetAddressType TC [RFC4001].

Although the SMI allows DEFVAL clauses for integer-valued
enumerations to specify the default value either by label or by
numeric value, the label form is preferred since all the examples in
RFC 2578 are of that form and some tools do not accept the numeric
form.

- If the value range is between -2147483648..2147483647 (inclusive)
and negative values are possible, then:

- Integer32 is RECOMMENDED;
- INTEGER is acceptable;
- Unsigned32 and Gauge32 MUST NOT be used.

- If the value range is between 0..4294967295 (inclusive) and the
value of the information being modelled may increase above the
maximum value or decrease below the minimum value, then:

[tronite]

The history table storage is indeed an issue which needs to be addressed, however, the zabbix_server source code for the SNMP poller also has issues with nagative integers. It appears that the SNMP poller handles all "INTEGER" types returned by SNMP clients as unsigned 64 bit integers, probably because of the issue with the history table only storing values as unsigned, however according to the SNMP specification, INTEGER and INTEGER32 types are 32 bit signed values, UNSIGNED32 and GAUGE32 are unsigned 32 bit integers...

You guys read a lot hey!

[alexwaller]

Wow, negative values are not supportet.
I like it.
But how shall I solve my problem?
I get:
MIKROTIK-EXPERIMENTAL-MIB::mtxrWlStatStrength.2 = INTEGER: -56
And now?
Anyone any idea? Patches? Solutions?

[Alexei]

We are gointg to fix it in 1.4.1 for doubles and introduce support of Signed Int64 in the next major release.

[alexwaller]

Thanks for your answer.
Any idea when 1.4.1 will be out?
Is it usefull to harvest the values right now? Any way to convert them then?

[tronite]

Is it out yet? Ahh! I should look at the announcements!