SNMP via PHP 5.3 - force numeric enums

[jacobl]

Hello,
We've are using SNMP via PHP 5.3 with the cmd.php poller with Cacti 0.8.8b, and have noticed an issue with how values for enums are returned. We use MIB parsing for readability on our data sources, and it seems that when MIBs are available to the PHP SNMP module the default format for a returned enum int value includes the string representation of the value too. Eg from an Eaton UPS getting the battery ABM status via "XUPS-MIB::xupsBatteryAbmStatus.0" we get back a value of "INTEGER: batteryFloating(3)" instead of "INTEGER: 3". This causes the poller to choke on the value, returning "WARNING: SNMP Get Timeout" and "WARNING: Result from SNMP not valid."

Previously we were using PHP 5.2 with Cacti, which didn't seem to exhibit this behaviour - maybe due to the SNMP module in that version being based on UCD-SNMP rather than NET-SNMP. We don't want to remove the MIBs to stop this enum parsing - and it appears there's a way to force the PHP SNMP module to output enums as numeric only using the snmp_set_enum_print() function.

We've hacked up our "lib\snmp.php" file to add "snmp_set_enum_print(1);" after every "snmp_set_quick_print(0);" call so that this setting is changed on each PHP SNMP branch and it does the trick. Is this the right place to put this call or is there a better location? Alternatively, is there already a bug logged for this? I couldn't find any in my quick searching.

Regards,

Jacob


Operating System: Windows Vista SP2 x64
Webserver: IIS 7.0
Cacti: 0.8.8b
Spine: n/a - using cmd.php
MySQL: 5.6
PHP: 5.3.28
RRDTool (Cygwin or Win32 build): Win32 - 1.2.x
Net-SNMP: 5.5
Cygwin (cygwin1.dll version): n/a
Plugin Architecture: 3.1

[BSOD2600]

What type of script is having this problem?

I don't believe this is a PHP 5.3 specific problem. For example, this script I designed in 2007 (http://docs.cacti.net/usertemplate:data ... nvironment) has the extra PHP MIB loading enabled to show the various MIB enum values. The snmp data query template didnt have a problem with the emum values.

[jacobl]

Hi BSOD2600,
We're not using a script for this device - the data template is just using the "Get SNMP Data" method.

Regards,

Jacob

[jacobl]

I've just had a quick run through the code - I'm not really familiar with PHP sorry - but the issue appears to be this:

- In lib\snmp.php, in cacti_snmp_get(), the @snmp3_get() function is returning a raw value of "INTEGER: batteryFloating(3)" in my above Eaton UPS example.

- format_snmp_string() is then called, which transforms this into "batteryFloating(3)"

- This is passed back out to the main cmd.php loop where it's passed into the strip_quotes() function. That function looks like this:

Code: Select all

function strip_quotes($result) {
	/* first strip all single and double quotes from the string */
	$result = trim(trim($result), "'\"");

	/* clean off ugly non-numeric data */
	if ((!is_numeric($result)) && (!is_hexadecimal($result)) && ($result != "U")) {
		$len = strlen($result);
		for($a=$len-1; $a>=0; $a--){
			$p = ord($result[$a]);
			if ((($p > 47) && ($p < 58)) || ($p==85)) {
				$result = substr($result,0,$a+1);
				break;
			}
		}
	}

	return($result);
}

It appears to walk backwards through the string until it finds the last numeric or "U" char, then returns all of the chars from the start of the string to that point. This results in the value now becoming "batteryFloating(3".

- The validate_result() function is then called on this value - and it fails this first check:

Code: Select all

	/* check the easy cases first */
	/* it has no delimiters, and no space, therefore, must be numeric */
	if ((substr_count($result, ":") == 0) && (substr_count($result, "!") == 0) && (substr_count($result, " ") == 0)) {
		$checked = true;
		if (is_numeric($result)) {
			$valid_result = true;
		} else if (is_float($result)) {
			$valid_result = true;
		} else {
			$valid_result = false;
			$result = "U";
		}

Falling into the last else case. This code seems to expect only strings containing numeric, ":", "!" or space chars.


Regards,

Jacob

[BSOD2600]

gotcha. please report the bug and reference this thread. http://www.cacti.net/bugs.php

[jacobl]

Done: http://bugs.cacti.net/view.php?id=2419

Hopefully put it in the right place - let me know if you want this bug reclassified, etc.

Thanks!

Regards,

Jacob

[BSOD2600]

looks good.

now just a matter of when the devs have time to investigate...