snmp string to float conversion

[JoelG]

1.6.3 Update?

Any word if the 1.6.3 update handles this situation? Or does a new patch need to be developed (again)?

Answer to my own question, is that it looks like the patch is not included, but it should be very easy to update. I am not sure as to how soon I will be able to test it though, so will hold off posting my fix until I do.

[jmb]

Here we go again. Patch against 1.6.3

Greets jm

[Alexei]

Here we go again. Patch against 1.6.3

What?! I was quite sure there are no issues with processing of string in 1.6.3 anymore.

I would appreciate if you could describe what the proposed patch is doing? What problem does it fix?

[Vitaly]

No, Alexei.
There is the same issue. The patch fixes it as before.

Thanks Jmb.

[Alexei]

No, Alexei.
There is the same issue. The patch fixes it as before.

What issue? Please tell us what exactly does not work. That's what I'd like to hear.

[JoelG]

Possible issue

Here is the core of the patch - first the test for octet string, then the test for item->value_type of FLOAT, then a string to double conversion (with a little extra debug info):

if (vars->type == ASN_OCTET_STR)
{
     /* fix for str to float conversion */
     if(item->value_type == ITEM_VALUE_TYPE_FLOAT)
     {
          vars->val.string[vars->val_len] = NULL; 

          SET_DBL_RESULT(value, strtod((char*)vars->val.string, (char **) NULL));
					
          zabbix_log( LOG_LEVEL_DEBUG, "s2f:OID [%s] Type [%d] value [%f]", snmp_oid, vars->type, value->dbl);
          zabbix_log( LOG_LEVEL_DEBUG, "s2f:val.string [%s]", vars->val.string);
          zabbix_log( LOG_LEVEL_DEBUG, "s2f:val_len [%d]", vars->val_len);
					
}

My guess as to why this hasn't been supported has always been that a device returning a string that needs to be interpreted as a float is out of spec, but that is a pure guess on my part.

To recap the problem, the device returns a string, we want/need to store it as a float.

[Alexei]

To recap the problem, the device returns a string, we want/need to store it as a float.

But this works out of the box in 1.6.3! I still have absolutely no idea why a patch is required.

Please give me a hint. All I need is a real non-working case.

[Vitaly]

Example:
Sensor Humidity
Type: SNMPv1 Agent
OID: SNMPv2-SMI::enterprises.16174.4.1.16174.1.1.3.3.3.6.0
Type: Numeric (float)

It does not work without the patch.

[Alexei]

Example:
Sensor Humidity
Type: SNMPv1 Agent
OID: SNMPv2-SMI::enterprises.16174.4.1.16174.1.1.3.3.3.6.0
Type: Numeric (float)

It does not work without the patch.

What values does snmpwalk return for this OID?

[Vitaly]

What values does snmpwalk return for this OID?

Where I can see it?

[JoelG]

Examples

Here is an example from the device I have - a string value that needs to be evaluated as a numeric, specifically as a float to support negative numbers:

# snmpwalk -v 1 -c public x.x.x.x SNMPv2-SMI::enterprises.303.3.3.16.2.1.3.29.0
SNMPv2-SMI::enterprises.303.3.3.16.2.1.3.29.0 = STRING: "49"
# snmpwalk -v 1 -c public x.x.x.x SNMPv2-SMI::enterprises.303.3.3.16.2.1.3.29.0
SNMPv2-SMI::enterprises.303.3.3.16.2.1.3.29.0 = STRING: "40"

This is no different from the very first post in this thread.

Still very much love Zabbix, hope to get this resolved.

[Alexei]

I see what you mean. It looks like we've found what was wrong in the code. The problem is fixed.

I would appreciate if you could download the latest nightly build from www.zabbix.com/developers.php and check if it works fine without any patches now. Please be hurry, we are releasing 1.6.4 today!

[JoelG]

Not a good beta tester

I'm sorry, I am not a good candidate for testing patches. I only have access to a full production system, so I usually lag a few days after an official update before I deploy a new version.

Hopefully, one of the other users who post to this thread can give your patch a quick try.

[Alexei]

Anyway Zabbix 1.6.4 is out. Give it a try!

[Vitaly]

Just updated zabbix to v1.6.4 - The same problem.

Applied the patch for v.1.6.3 - Works fine.