Duplicate Value output when I query a uniqe OID ???

[ronjonix]

Has anybody seen this before? This is an APC netbotz 450 device. The Humidity and Dew Point sensors report uniquely just fine, but this temperature device does not. The APC forums were no help so I decided to turn here.

Here is the example:

root@cltnms01:$ snmpwalk -On -c <password> -v 2c <APC device> .1.3.6.1.4.1.5528.100.4.1.1.1.9

.1.3.6.1.4.1.5528.100.4.1.1.1.9.1619732064 = INTEGER: 92 (Temperature 2)
.1.3.6.1.4.1.5528.100.4.1.1.1.9.3406802758 = INTEGER: 72 (Temperature 3)

root@cltnms01:$ snmpwalk -On -c <password> -v 2c <APC device> .1.3.6.1.4.1.5528.100.4.1.1.1.9.1619732064

.1.3.6.1.4.1.5528.100.4.1.1.1.9.3406802758 = INTEGER: 72 (returns the same OID/value as Temperature 3 ????)

root@cltnms01:$ snmpwalk -On -c <password> -v 2c <APC device> .1.3.6.1.4.1.5528.100.4.1.1.1.9.3406802758

.1.3.6.1.4.1.5528.100.4.1.1.1.9.3406802758 = INTEGER: 72 (Temperature 3)

thanks for any help you can give!,

ron

 

[bnorton916]

Do you have the MIB for this?

 

[ronjonix]

MIB information:

.1.3.6.1.4.1.5528.100.4.1.1.1.1.1619732064 = STRING: "nbAlinkEnc_0_2_TEMP"
.1.3.6.1.4.1.5528.100.4.1.1.1.1.3406802758 = STRING: "nbAlinkEnc_0_3_TEMP"
.1.3.6.1.4.1.5528.100.4.1.1.1.2.1619732064 = INTEGER: 343
.1.3.6.1.4.1.5528.100.4.1.1.1.2.3406802758 = INTEGER: 229
.1.3.6.1.4.1.5528.100.4.1.1.1.3.1619732064 = INTEGER: 0
.1.3.6.1.4.1.5528.100.4.1.1.1.3.3406802758 = INTEGER: 0
.1.3.6.1.4.1.5528.100.4.1.1.1.4.1619732064 = STRING: "Temperature (2)"
.1.3.6.1.4.1.5528.100.4.1.1.1.4.3406802758 = STRING: "Temperature (3)"
.1.3.6.1.4.1.5528.100.4.1.1.1.5.1619732064 = STRING: "nbAlinkEnc_0"
.1.3.6.1.4.1.5528.100.4.1.1.1.5.3406802758 = STRING: "nbAlinkEnc_0"
.1.3.6.1.4.1.5528.100.4.1.1.1.6.1619732064 = ""
.1.3.6.1.4.1.5528.100.4.1.1.1.6.3406802758 = ""
.1.3.6.1.4.1.5528.100.4.1.1.1.7.1619732064 = STRING: "34.300000"
.1.3.6.1.4.1.5528.100.4.1.1.1.7.3406802758 = STRING: "22.900000"
.1.3.6.1.4.1.5528.100.4.1.1.1.8.1619732064 = INTEGER: 34
.1.3.6.1.4.1.5528.100.4.1.1.1.8.3406802758 = INTEGER: 22
.1.3.6.1.4.1.5528.100.4.1.1.1.9.1619732064 = INTEGER: 93
.1.3.6.1.4.1.5528.100.4.1.1.1.9.3406802758 = INTEGER: 73
.1.3.6.1.4.1.5528.100.4.1.1.1.10.1619732064 = Counter32: 1619732064
.1.3.6.1.4.1.5528.100.4.1.1.1.10.3406802758 = Counter32: 3406802758

So whenever the unique object 1619732064 is queried it returns the value for the other sensor, but in the snmp stack it shows up as the real value of the sensor.

 

[bnorton916]

Not really sure what it going on. Looks like the agent is messed up.

Having such huge values for an index is quite...odd.

It would be interesting to see if snmpwalk is sending a getnext or getone. I am wondering if the index value being over 2^31 is causing the problem.

Do other snmp managers show this odd behavior?

Bill

 

[ronjonix]

Ok I got an answer back from APC and they were not able to duplicate the problem. This prompted me to try the snmpwalk from another server RHEL 5 and it worked. The problem server is a RHEL 6, I have since contacted Red Hat to see what they come up with. It's not a show stopper since I can still get data from snmp for this device, but it will just be more clunky.

thanks for the response!

Ron