Cacti SNMP V3 Issues

[stevosoft]

Hi,
I have just installed the latest version (0.8.7g) and am having issues with servers running snmp v3. I am able to run snmpwalk successfully to these hosts but the cacti php scripts (for example /var/www/html/cacti/scripts/ss_host_disk.php) always timeout and I'm left with the host having an SNMP error.

Has anyone seen this and solved it? I kindof expect that if snmpwalk is able to connect than it can't be an snmp error so as far as I can see it looks like the cacti php scripts that are the problem.

Steve

[stevosoft]

My tech support info is....

Date Tue, 28 Sep 2010 16:03:51 +1000
Cacti Version 0.8.7g
Cacti OS unix
SNMP Version NET-SNMP version: 5.3.2.2
RRDTool Version RRDTool 1.4.x
Hosts 69
Graphs 888
Data Sources Script/Command: 62
SNMP: 916
SNMP Query: 198
Script Query - Script Server: 226
Total: 1402

[TheWitness]

Use the script server debug method to test the scripts.

[stevosoft]

A bit vague. When I turn debug mode on all I get is Poller message saying that the host didn't respond to SNMP. I already knew this because running the script from the command line has the same result. Looking at /var/log/messages on the remote host tells me that an attempt to connect using snmp has occurred. SNMPWALK works without error from the command line. I have put print statements through the script in an attempt to find the broken code.

[TheWitness]

Post it...

[stevosoft]

[SOLVED] OK - I have been able to debug the issue using tcpdump and reading the snmp packets. It basically came down to an invalid context string being sent to snmp from the script. I am fortunate enough to have an older version of cacti running here and was able to do a side-by-side packet comparison. The old server and the new server polling and snmp info were setup identically via the GUI but the old server script doesn't send a contextName (even though there is one in the GUI field) and the new server script sends the contextName from that field. SNMP at the other end sees this as an invalid contextName and sends back the appropriate MIB. The new script just ignores this message and attempts 4 get-next-request.

As soon as I removed the context string from the request the SNMP requests worked correctly. This being an SNMPV3 issue tcpdump by itself doesn't give you any useful packet info but if the trace is loaded into wireshark you can set it up to show the packet data. There is a bit of work involved and it would have been easier if the cacti.log in debug mode actually displayed a relevant looking error instead of the generic looking SNMP Timeout error - the script is actually getting back some useful MIB info that could be handled by a few lines of code or at least displayed in the debug log file. It would also have been a bit easier to read the code if it had a few comments explaining what it was trying to do rather than hiding behind clever obfuscated code.