Re: Cacti not graphing on hosts acting as SNMP server devices - version 0.8.8a

On 09.05.2012 14:30, Kaya Saman wrote:
>>>
>>> The other machine that I have which is CentOS 6.2 x64 based running
>>> net-snmp from the EPEL repos.... is still not working:
>>>
>>> Output from snmpget:
>>>
>>> snmpget -c 4622b8ba -v 2c 172.31.8.16 1.3.6.1.2.1.25.1.1.0
>>> HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (75939008) 8 days, 18:56:30.08
>>>
>>>
>>> Uptime if I understand correctly is 8 days +.....
>>>
>>>
>>> So why doesn't Cacti then see this?
>> There are two uptimes
>> - hrSystemUptime == uptime of the system (but this is an OPTIONAL MIB)
>> - sysUptime == uptime of the snmpd on target system (and there have been restart
>> scripts to restart snmpd each week since long ...)
>> so both may differ. We refer to the last one.
>>
>>
>>>
>>> The web-ui shows this:
>>>
>>> SNMP Information
>>> System:Linux uk-lon-nag-1.rjis.co.uk 2.6.32-220.13.1.el6.x86_64 #1 SMP Tue
>>> Apr 17 23:56:34 BST 2012 x86_64
>>> Uptime: 9411 (0 days, 0 hours, 1 minutes)
>>
>> That's sysUptime!
>>
>>> Hostname: uk-lon-nag-1.rjis.co.uk
>>> Location: Monitoring Cluster
>>> Contact: Master Kaya Saman
>>>
>>>
>>> But under Console it shows as down:?
>> That is indeed strange.
>>
>>>
>>> What information could I provide for this host to be useful?
>>>
>>>
>>> The log shows that SNMP is querying the system:
>>>
>>> May  9 11:59:08 uk-lon-nag-1 snmpd[12567]: Connection from UDP:
>>> [172.31.8.17]:16996->[172.31.8.16]
>> Please have a look, which request and which response is exchanged. Is it a
>> sysUptime request and is there any response? A tcpdump/wireshark trace may help.
>> Are you running spine or cmd.php?
>>
> 
> I am running cmd.php
> 
> 
> This is output of tcpdump:
> 
> 
> uk-lon-cacti-1# tcpdump -vv host 172.31.8.16
> tcpdump: listening on bce0, link-type EN10MB (Ethernet), capture size 96 bytes
> 13:23:42.642670 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> 172.31.8.32 tell 172.31.8.16, length 46
> 13:23:42.752671 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> 172.31.8.33 tell 172.31.8.16, length 46
> 13:23:47.600015 IP (tos 0x0, ttl 64, id 15613, offset 0, flags [none],
> proto UDP (17), length 74)
>     uk-lon-cacti-1.rjis.co.uk.38206 > 172.31.8.16.snmp: [bad udp cksum
> f679!]  { SNMPv2c C=4622b8ba { GetRequest(29) R=1773774262  25.1.1.0 }
> }
> 13:23:47.600474 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 77)
>     172.31.8.16.snmp > uk-lon-cacti-1.rjis.co.uk.38206: [udp sum ok]
> { SNMPv2c C=4622b8ba { GetResponse(32) R=1773774262  25.1.1.0=458469 }
> }
...
>     172.31.8.16.snmp > uk-lon-cacti-1.rjis.co.uk.19739: [udp sum ok]
> { SNMPv2c C=4622b8ba { GetResponse(31) R=1476554716
> system.sysUpTime.0=474915 } }
> 
> 
> I do see some "Bad UDP checksum" statements....
I don't think so.
The responses seem to be ok.

Please see the cacti about.php page to find out, whether we are using php-snmp
or not.
Let us try to see php-snmp versus net-snmp and cmd.php versus spine to find out

Reinhard

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/