snmp string to float conversion

[JoelG]

My upgrade to version 1.6 has gone smoothly except for one issue.

I have one item that is a temperature value (in Celsius) , and it is returned as a string. I need to convert to float to support negative numbers.

Example:

SNMPv2-SMI::enterprises.XXX.3.3.16.2.1.3.29.0 = STRING: "36"

For some reason, and it seems to be random, the value gets processed as 10, 100, 1000 or even 1B times higher. I have temperature values showing as:

366 C
43.04 KC
43.98 GC

Clearly, these are wrong, and the triggers are continuous, and now the trend data is worthless.

I tried looking at checks_snmp.c, but nothing immediately jumped out at me besides the second parameter to strtod, which should be (char **) NULL, not 0. Could this be the problem?

[JoelG]

Debugging Follow-up

I have added extensive debugging output to checks_snmp.c to see what the problem can be, and I think I have found the problem.

The variable vars->val.string is not initialized to (blank,null,zeros) each time it is used, so there can be quite an array of garbage in there. The vars->val_len field will have the correct length of the string being processed, but the strtod() function does not have a length field option, so if the vars->val.string just happens to have ascii characters, such as [0-9], they will be used in the string to double conversion.

Not sure what the best work-around is, I am going to force a null into vars->val.string at the vars->val_len position before the call to strtod().

[Alexei]

Thanks for debugging this! Registered as ZBX-533.

[JoelG]

The Fix

Here is the actual code I have used to fix and debug the problem. This seems to be working, as I have had no bad data reported in the last 16 hours, and I was getting hundreds of errors before.

The debug messages showed that the string could hold quite a bit of garbage. While this fix works, and I think guarantees the strtod() gets a valid string, I think the long term solution requires better initialization of the underlying data structure (whatever inits vars probably should use memset(), for example).

Interestingly, the 1.4.x branch never exhibited this behavior, but the 1.6 did right from the start.

vars->val.string[vars->val_len] = NULL;  /* CODE FIX */
					
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);

[Alexei]

The issue has been fixed. Please wait for 1.6.1.

[rrr]

Why it is not included in the nightly builds? And when will 1.6.1 be released?

[Alexei]

Why it is not included in the nightly builds? And when will 1.6.1 be released?

It is included!

[rrr]

I've downloaded Revision 6221 and the problem still exists. Some OIDs which were collected successfully with 1.4.6 and the initial release of 1.6, will be reported with "invalid value type".
All of these OIDs are strings wich are typed in zabbix as float.

[rrr]

Now in Revision 6225 I see in the Changelog that the bug should be fixed ([ZBX-533] fixed incorrect SNMP string to float conversion), but it isn't.

Evertyime I reactivate the faulty items a second later zabbix switch them back to "not supported".

[vrtareg]

Hi

I had the same problem after upgrading to latest 1.6.x version.
After comparing to 1.6 release i see that there are additional code at the end of "checks_snmp.c" file:

	if (SUCCEED == ret && NULL == get_result_value_by_value_type(value, item->value_type))
	{
		zbx_snprintf(error, sizeof(error), "OID [%s] invalid value type", item->snmp_oid);
		zabbix_log(LOG_LEVEL_ERR, "%s", error);
		SET_MSG_RESULT(value, strdup(error));

		ret = NOTSUPPORTED;
	}

When i comment out this part I start to receive correct values for:

snmpget -c public -v1 tempsensor01 .1.3.6.1.4.1.16174.1.1.1.3.1.2.0
SNMPv2-SMI::enterprises.16174.1.1.1.3.1.2.0 = STRING: "19.0"

Regards
Areg

[vrtareg]

Hi

It seems that i do wrong modifications.
I start to receive 0 values.

Hi

I had the same problem after upgrading to latest 1.6.x version.
After comparing to 1.6 release i see that there are additional code at the end of "checks_snmp.c" file:

	if (SUCCEED == ret && NULL == get_result_value_by_value_type(value, item->value_type))
	{
		zbx_snprintf(error, sizeof(error), "OID [%s] invalid value type", item->snmp_oid);
		zabbix_log(LOG_LEVEL_ERR, "%s", error);
		SET_MSG_RESULT(value, strdup(error));

		ret = NOTSUPPORTED;
	}

When i comment out this part I start to receive correct values for:

snmpget -c public -v1 tempsensor01 .1.3.6.1.4.1.16174.1.1.1.3.1.2.0
SNMPv2-SMI::enterprises.16174.1.1.1.3.1.2.0 = STRING: "19.0"

Regards
Areg

[Alexei]

"19.0" - this is not a float (do you see the quotes?)
19.0 - this is a float value, it will be processed fine

Hmm, I think we will implement an extra check to specially process quoted numbers. It is nothing to do with the original problem.

[vrtareg]

Hi Alexei

Yes i see this.
But how this works in 1.6 version?
You change check mechanism in new version?

Regards
Areg

[rrr]

In the initial release of 1.6 this problem didn't exists. Only in the "last" Nightly Builds I recognized this error.

[JoelG]

Check original message

This is very much tied to the original problem.

A string, which is a signed integer, has to be converted to a float, to be supported.