No SNMP data returned; but command line query OK

[CerpherJoe]

I've isolated the problem to a line in snmp.php that uses an array called @snmp2_real_walk:

$temp_array = @snmp2_real_walk("$hostname:$port", "$community", "$oid", ($timeout * 1000), $retries);

The array is empty, causing the problem. All input values are OK.

I cannot find the @snmp2_real_walk array anywhere, but grep gives me a hint that it might be in 'snmp.so.'

Is it possible that cacti does not have proper php access to 'snmp.so'?

How can I make sure snmp.so is properly available to cacti?

Thanks!

Joe

[CerpherJoe]

(switching over from mailing list)

Reinhard,

Yes, clicking on the cactus yields:

PHP SNMP Support: yes

snmp.php: (cacti_snmp_walk entry point)

$temp_array = @snmp2_real_walk("$hostname:$port", "$community", "$oid", ($timeout * 1000), $retries);

This array is empty, thus returning an empty $snmp_array to the calling routine, data_query.php. data_query then immediately checks to see if this array is empty, and if so, prints:

"No SNMP data returned"

Note: Cacti *is* sending out SNMP requests (I thought this was not the case earlier, so I'll continue to be digging into things in the meantime.)

loiaconoj@ubuntu7:/usr/share/cacti/site/lib$ tcpdump port 161
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes

09:33:22.531255 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetBulk(29) N=0 M=20 interfaces.ifTable.ifEntry.ifIndex
09:33:23.040050 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetBulk(29) N=0 M=20 interfaces.ifTable.ifEntry.ifIndex
09:33:23.541331 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetBulk(29) N=0 M=20 interfaces.ifTable.ifEntry.ifIndex
09:33:24.050350 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetBulk(29) N=0 M=20 interfaces.ifTable.ifEntry.ifIndex
09:33:24.560439 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetRequest(28) system.sysUpTime.0
09:33:25.070078 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetRequest(28) system.sysUpTime.0
09:33:25.571215 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetRequest(28) system.sysUpTime.0
09:33:26.079974 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetRequest(28) system.sysUpTime.0
09:33:26.689472 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetRequest(28) system.sysDescr.0
09:33:27.191333 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetRequest(28) system.sysDescr.0
09:33:27.700471 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetRequest(28) system.sysDescr.0
09:33:28.201612 IP vm15.open.web.32771 > 172.16.224.192.snmp: C=public GetRequest(28) system.sysDescr.0

In the tcpdump output there are no responses; but the 3 retries.

Thanks,

Joe

[CerpherJoe]

OK, one thing I've noticed from TCPDUMP, compared to command line SNMP queries, cacti is not receiving responses. So, something must be wrong in how it is formulating the query?

Joe

[CerpherJoe]

Here are the tcpdump traces for cacti, and the cli:

CACTI:

10:34:13.426452 IP vm15.open.web.32778 > 172.6.124.192.snmp: C=public GetBulk(29) N=0 M=20 interfaces.ifTable.ifEntry.ifIndex

CLI:

10:27:45.889478 IP vm15.open.web.32777 > host-124-192.gross.org.snmp: C=public GetBulk(29) N=0 M=10 interfaces.ifTable.ifEntry.ifIndex

10:27:45.891929 IP host-124-192.gross.org.snmp > vm15.open.web.32777: C=public GetResponse(185) interfaces.ifTable.ifEntry.ifIndex.1=1 [|snmp]

Notice the difference in M values? What is M?

[CerpherJoe]

Ah ha. M seems to control the number of indexes per UDP response packet, and I've seen this problem somewhere before on the forum.

... checking ...

[CerpherJoe]

Applied the patch suggested by aron6166 changing -Cr50 to Cr10 in snmp.php. This did not fix it.

I noticed that cacti is not receiving responses even for simple snmpgets:

CACTI:

11:12:55.607894 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0
11:12:56.110074 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0
11:12:56.610761 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0
11:12:57.111175 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0

(Original plus 3 retries)

CLI:

11:14:34.517340 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0
11:14:34.519117 IP 192.168.224.192.161 > 192.168.210.15.32779: C=public GetResponse(32) .1.3.6.1.2.1.1.3.0=1790690610

[CerpherJoe]

Solved.

Operator error.

Mistyped device IP address.



Reinhard - thanks for your kind and forbearing help.

Regards,

Joe

[TheWitness]

Well, thank goodness for that....

TheWitness

[gandalf]

Applied the patch suggested by aron6166 changing -Cr50 to Cr10 in snmp.php. This did not fix it.

I noticed that cacti is not receiving responses even for simple snmpgets:

CACTI:

11:12:55.607894 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0
11:12:56.110074 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0
11:12:56.610761 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0
11:12:57.111175 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0

(Original plus 3 retries)

CLI:

11:14:34.517340 IP 192.168.210.15.32779 > 192.168.224.192.161: C=public GetRequest(28) .1.3.6.1.2.1.1.3.0
11:14:34.519117 IP 192.168.224.192.161 > 192.168.210.15.32779: C=public GetResponse(32) .1.3.6.1.2.1.1.3.0=1790690610

In any case. This patch is not required. It's a host specific setting available for it. Or does it fail when simply calling the host edit screen for that very device?
Reinhard

[luke404]

I am resurrecting this old thread because I would have wrote the exact same subject and I'm having the exact same problem - but no operator error here

I am monitoring a D-Link DES-1228P switch on my Cacti-0.8.7i - just a single data source, Generic OID Template and oid = 1.3.6.1.2.1.105.1.3.1.1.4.1, that's PoE wattage through the switch. Now I wanted to add Ethernet interfaces traffic so I added the usual SNMP Interface Statistics data query but it sees no interfaces. Or, actually, it counts all the interfaces but no data from them:

Code: Select all

+ Running data query [1].
+ Found type = '3' [SNMP Query].
+ Found data query XML file at '/var/www/blablabla/cacti/resource/snmp_queries/interface.xml'
+ XML file parsed ok.
+ Executing SNMP get for num of indexes @ '.1.3.6.1.2.1.2.1.0' Index Count: 29
+ Executing SNMP walk for list of indexes @ '.1.3.6.1.2.1.2.2.1.1' Index Count: 0
+ No SNMP data returned

Running a commandline snmpwalk from the same Cacti host correctly returns interfaces, but the last one has a non contiguous index:

Code: Select all

$ snmpwalk -v2c -cpublic my.switch.ip.addr .1.3.6.1.2.1.2.2.1.1
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
[....]
IF-MIB::ifIndex.28 = INTEGER: 28
IF-MIB::ifIndex.604 = INTEGER: 604

At first after some googling I was suspecting the non-consecutive IDs (bug #2225) so I manually backported SVN #7340 into my Cacti-0.8.7i (basically adding -Cc options to net-snmp commands) but that made no difference.

After further investigation I saw that when running data queries through the Device page Cacti is actually using PHP's snmp2_real_walk() function and not the net-snmp one - that's in lib/snmp.php around line 310~316 (mine got some lines added, sorry).
I added some logging to it and I can confirm that function is not actually reading data from the host; I also ran some tcpdump and saw that SNMP queries are going to the host but responses are not coming back.

Other than that, all the snmp* tools from command line and all other cacti features (including running data queries on dozens of other hosts and running a single OID get on this switch) work perfectly.

Seems like PHP's snmp functions have some problems, probably a bug, don't know. I tried manually running the same function in a one-line php script and had the same results (ie. no answers from the host). I'll have to try on different PHPs on different hosts to elaborate more on this.

But also it seems like in some places Cacti-0.8.7i is using PHP's snmp walk functions even if configured to use net-snmp - is that a feature or a bug?

[gandalf]

See e.g. http://team-scheck.de/blog/?p=26 for a discussion.
In case this should match, please deinstall php-snmp to use net-snmp binaries. This will include a performance penalty; but when not using cmd.php, only web pages are affected and that should not cause too much trouble
R.

[luke404]

gandalf, I guess you got it right.

I tried switching to SNMPv1 (in Cacti's device config) and the data query started returning all the interfaces.

I created graphs for all the interfaces and they were working correctly, then I turned the device back to SNMPv2c and they still kept working. Not having to remove php-snmp is good because I got it compiled in the main PHP binary...

Thank you