Problem with "Wrong Type" SNMP-Answer

Post support questions that directly relate to Linux/Unix operating systems.

Moderators: Moderators, Developers

Post Reply
Author
Message
drenny
Posts: 10
Joined: Thu Dec 01, 2011 5:09 am

Problem with "Wrong Type" SNMP-Answer

#1 Post by drenny » Thu Dec 05, 2019 10:35 am

Hi Everybody

I have a problem with cacti and switches that return "Wrong Type" on a snmp-interface-query.

The graph of the corresponding interface look "strange". They are cut on top and completely wrong on the y-axis.

Image

If i query the interface from cli (FreeBSD), i get the following answer:

Code: Select all

snmpget -v 2c -c cacti 10.75.7.26 .1.3.6.1.2.1.31.1.1.1.10.67371008      
IF-MIB::ifHCOutOctets.67371008 = Wrong Type (should be Counter64): Hex-STRING: 00 00 00 2F E9 30 0B 2D

after some deep-diving in the snmp-query-poller-php-code i found out, that the "Wrong Type" information is somewhere lost or never exported and so no fix can be done on the returned values.

has anybody else this problem and can we fix this in one of the future releases of cacti and spine?

BRs
Thomas

User avatar
Osiris
Cacti Pro User
Posts: 889
Joined: Mon Jan 05, 2015 10:10 am

Re: Problem with "Wrong Type" SNMP-Answer

#2 Post by Osiris » Thu Dec 05, 2019 7:49 pm

Report this to your hardware vendor. They have a bug in their agent.
Before history, there was a paradise, now dust.

drenny
Posts: 10
Joined: Thu Dec 01, 2011 5:09 am

Re: Problem with "Wrong Type" SNMP-Answer

#3 Post by drenny » Fri Dec 06, 2019 12:29 am

I already did this. But how can this problem be "fixed" in Cacti?

User avatar
Osiris
Cacti Pro User
Posts: 889
Joined: Mon Jan 05, 2015 10:10 am

Re: Problem with "Wrong Type" SNMP-Answer

#4 Post by Osiris » Fri Dec 06, 2019 8:58 am

Basically, there is an option to not load MIB's. Do this test:
export MIBS=none
snmpwalk -c ... -v2c hostname oid
or
snmpget -c ... -v2c -On hostname oid
What is the output after that?
Before history, there was a paradise, now dust.

drenny
Posts: 10
Joined: Thu Dec 01, 2011 5:09 am

Re: Problem with "Wrong Type" SNMP-Answer

#5 Post by drenny » Mon Dec 09, 2019 12:49 am

Does not change anything on the answer (except that the OID is not expanded)...

Code: Select all

snmpget -v 2c -c ... -On <host> .1.3.6.1.2.1.31.1.1.1.10.67371008
.1.3.6.1.2.1.31.1.1.1.10.67371008 = Wrong Type (should be Counter64): Hex-STRING: 00 00 00 30 B4 96 31 AC 

netniV
Cacti Guru User
Posts: 3132
Joined: Sun Aug 27, 2017 12:05 am

Re: Problem with "Wrong Type" SNMP-Answer

#6 Post by netniV » Tue Dec 10, 2019 8:25 am

the fact that even the cli tools which are nothing to do with us, tell you the same thing, suggests that the bug is with the vendor and needs to be reported to them. We can't actually do anything about that.

drenny
Posts: 10
Joined: Thu Dec 01, 2011 5:09 am

Re: Problem with "Wrong Type" SNMP-Answer

#7 Post by drenny » Thu Dec 12, 2019 2:28 am

That's right: the source of the problem is a wrong implementation of the interface-counter in the SNMP-Agent.
BUT: the vendor is not able / willing to change this. So in the "old" 0.8.8 version, there was a fix in the poller / spine that fixed this problem, this fix is not working in 1.x anymore.

So can this be made in spine (i already did this in the php-version, but this version is to slow for 100'000 datasources)

BRs
Thomas

drenny
Posts: 10
Joined: Thu Dec 01, 2011 5:09 am

Re: Problem with "Wrong Type" SNMP-Answer

#8 Post by drenny » Mon Jan 06, 2020 8:38 am

i think i found a problem in the cacti-spine version:

at line ~700 in snmp.c in the developer-version of cacti you find this line of code:

Code: Select all

snprintf(snmp_oids[i].result, RESULTS_BUFFER, "%s", trim(strip_alpha(temp_result)));
when temp_result is a (invalid) response to an SNMP query with a hex-answer (something like) :

Code: Select all

IF-MIB::ifHCInOctets.167862272 = Wrong Type (should be Counter64): Hex-STRING: 00 00 00 02 41 CF B4 DC 
the part of strip_alpha removes the characters at the end of the snmp-answer (if there are any). So the traffic gets completely wrong as the last numbers in the hex-string are missing... (00 00 00 02 41 CF B4 DC becomes 00 00 00 02 41CF B4 - DC is removed)

BRs
Thomas

Post Reply