Wrong string numerical value got from Cacti SNMP poller

[GLR]

I have a data retrieved through SNMP from a Net-SNMP/UCD exec command. This data which is actually a number is retrieved as a string (see OID .1.3.6.1.4.1.2021.8.1.101 - extOutput - in UCD-MIB extTable branch, its data type is string).

When performing the SNMPGet, Cacti retrieves a wrong value : 21088 whereas the right one we get though an external snmpget command is 5260 (this is a 802.11an frequency (MHz) on a device running OpenWrt).

A workaround I found is to make the snmp exec called script on host provide a negative value, it is then correctly retrieved by Cacti.

- Here are Cacti detailed logs :

Wrong :

Code: Select all

POLLER: Poller[0] CACTI2RRD: /usr/bin/rrdtool update /usr/share/cacti/rra/host_wl_ap_freq_1545.rrd --template wl_ap_freq 1281357006:21088
SPINE: Poller[0] Host[72] TH[1] DS[1545] SNMP: v2: 192.168.0.245, dsname: wl_ap_freq, oid: 1.3.6.1.3.1981.80.91.101.1, value: 21088

Right :

Code: Select all

POLLER: Poller[0] CACTI2RRD: /usr/bin/rrdtool update /usr/share/cacti/rra/host_wl_ap_freq_1537.rrd --template wl_ap_freq 1281357006:-5260
SPINE: Poller[0] Host[72] TH[1] DS[1537] SNMP: v2: 192.168.0.245, dsname: wl_ap_freq, oid: 1.3.6.1.3.1981.80.7.101.1, value: -5260

- snmpwalk output :

Code: Select all

1.3.6.1.3.1981.80.91.1.1 = INTEGER: 1
1.3.6.1.3.1981.80.91.2.1 = STRING: "get-test-ap-freq-0"
1.3.6.1.3.1981.80.91.3.1 = STRING: "/usr/local/bin/get-test-ap-freq.sh wlan0"
1.3.6.1.3.1981.80.91.100.1 = INTEGER: 0
1.3.6.1.3.1981.80.91.101.1 = STRING: "5260"
1.3.6.1.3.1981.80.91.102.1 = INTEGER: 0
1.3.6.1.3.1981.80.91.103.1 = ""

- Script called by exec in the polled device :

Code: Select all

# cat get-test-ap-freq.sh
#!/bin/sh
# $1 = wlan interface name
val=$(iw dev $1 survey dump | grep frequency | cut -d':' -f2 | cut -d' '
 -f1)
printf "%d\n" $val

[BSOD2600]

cmd.php poller have the same issue?

Please report the spine bug: http://www.cacti.net/bugs.php

[GLR]

Yes, smart remark !

I've just tested : it is only spine, cmd.php returns the right value.

[BSOD2600]

If you're feeling brave, you could checkout the latest spine from the svn and compile. I know TheWitness has been doing more spine dev work lately.

Please create a bug report for spine and reference this post in it.

[GLR]

Yes, I will do both tomorrow.
Thx.

[TheWitness]

Set max oids on the host to one. This is an agent issue.

TheWitness

[GLR]

I don't think so...

Max OID set to 1, but same result, still using spine stable version 0.8.7g.

- Cacti logs with results :

Code: Select all

08/10/2010 03:40:07 PM - SPINE: Poller[0] Host[72] TH[1] DS[1545] SNMP: v2: 192.168.0.245, dsname: wl_ap_freq, oid: 1.3.6.1.3.1981.80.91.101.1, value: 21088 

- tcpdump :

Code: Select all

# tcpdump -i eth1 -n -p -s 1500 host 192.168.0.245 and port 161
15:40:07.403703 IP 172.16.0.4.39036 > 192.168.0.245.161:  C=mycom GetRequest(32)  .1.3.6.1.3.1981.80.91.101.1
15:40:07.427139 IP 192.168.0.245.161 > 172.16.0.4.39036:  C=mycom GetResponse(37)  .1.3.6.1.3.1981.80.91.101.1="5260"

[GLR]

See : http://bugs.cacti.net/view.php?id=1829

[TheWitness]

If you look at your dump, the response to the request are different numbers. So, something is not right. The request is #32 and the response was #37, they are obviously different requests. So, there is something else going wrong and it's all about the word 'agent' not spine.

TheWitness

[GLR]

No, this is the normal behavior. The numbers between brackets are not sequence numbers but probably payload sizes.

Btw you can see that the source port is the same, so this is the right UDP exchange.

[TheWitness]

This is pretty unusual. If the max_oid's at the host level is 1, then the OID's will be gathered from the host one at a time and should always be in the correct order unless there is a problem with the agent, they should always be correct.

Normally, at this point, we would do a GotoMeeting. Do you have some time for this? I have a very small window this morning, and then won't be able to meet again until next week.

TheWitness

[GLR]

Thank you for your help, but I think it will not be necessary : I've found a workaround and I am about to leave for vacations.
Btw it is very easy to reproduce the issue...

[TheWitness]

Well, when you get back from holidays, contact me again, and we can go over the problem in detail together so that I fully understand what is happening.

TheWitness

[mkalle]

i am seeing the same issue after upgrade from 0.8.7d to g


08/17/2010 12:31:02 PM - SPINE: Poller[0] Host[114] DS[1894] SNMP: v1: host.u.net, dsname: TotalResponseBytes, oid: .1.3.6.1.4.1.5951.4.1.3.1.1.33.13.67.83.86.73.80.95.97.111.97.97.46.100.107, value: 865048505341
08/17/2010 12:34:02 PM - SPINE: Poller[0] Host[114] TH[1] DS[1894] SNMP: v1: host.u.net, dsname: TotalResponseBytes, oid: .1.3.6.1.4.1.5951.4.1.3.1.1.33.13.67.83.86.73.80.95.97.111.97.97.46.100.107, value: 147680052483893
08/17/2010 12:35:02 PM - SPINE: Poller[0] Host[114] TH[1] DS[1894] SNMP: v1: host.u.net, dsname: TotalResponseBytes, oid: .1.3.6.1.4.1.5951.4.1.3.1.1.33.13.67.83.86.73.80.95.97.111.97.97.46.100.107, value: 147680338051652


snmpwalk -v 1 -c hidden ns1.u.net .1.3.6.1.4.1.5951.4.1.3.1.1.33.13.67.83.86.73.80.95.97.111.97.97.46.100.107
SNMPv2-SMI::enterprises.5951.4.1.3.1.1.33.13.67.83.86.73.80.95.97.111.97.97.46.100.107 = STRING: "866944383385"

i have tried setting the max oids returend to 1, its was at 10. but this hasnt changed anything.

as you can see in the pasted log files, the first retrive is OK, and then it fails.

[TheWitness]

Yea, seeing that too. Crap. I need someone to work with me at identifying the source of the regression.

TheWitness