Temperature SNMP Get test

When you post information about some problem, please include the following details: - OS version (e.g. Windows 2000 Professional SP3); HostMonitor version; problem description.
Post Reply
ksn
Posts: 3
Joined: Tue Sep 07, 2010 2:08 am

Temperature SNMP Get test

Post by ksn »

Helo!

I have a little problem with SNMP Get test, with APC Rack Air Removal Unit SX device.

3 termo sensors:

OID: .1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.X

GetIF .1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.1 = 26 C - real temperature
HM .1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.1 = 31 C

GetIF .1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2 = 20 C - real temperature
HM .1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2 = 31 C

GetIF .1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.3 = 30 C - real temperature
HM .1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.3 = 31 C

Sorry my bad english.
KS-Soft
Posts: 12821
Joined: Wed Apr 03, 2002 6:00 pm
Location: USA
Contact:

Post by KS-Soft »

Can we get access to your device?

Regards
Alex
ksn
Posts: 3
Joined: Tue Sep 07, 2010 2:08 am

Post by ksn »

yes, on your mail.
KS-Soft
Posts: 12821
Joined: Wed Apr 03, 2002 6:00 pm
Location: USA
Contact:

Post by KS-Soft »

Thank you for access to the device.

We tested HostMonitor and MIB Browser - they show the same results while HostMonitor uses our own SNMP API, MIB Browser uses Windows SNMP API.
Also we checked network traffic using WireShark - your device returns number 31.

This means our software works correctly. If some other utility provides different results, I think you should contact developers of that utility.

Regards
Alex
ksn
Posts: 3
Joined: Tue Sep 07, 2010 2:08 am

Post by ksn »

GetIf - utilite

No. Time Source Destination Protocol Info
148 7.518582 192.168.250.110 192.168.2.30 SNMP get-response 1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2

Frame 148: 100 bytes on wire (800 bits), 100 bytes captured (800 bits)
Ethernet II, Src: Cisco_d0:e6:d1 (00:0c:85:d0:e6:d1), Dst: AsustekC_c2:a9:52 (00:26:18:c2:a9:52)
Internet Protocol, Src: 192.168.250.110 (192.168.250.110), Dst: 192.168.2.30 (192.168.2.30)
User Datagram Protocol, Src Port: snmp (161), Dst Port: 49448 (49448)
Simple Network Management Protocol
version: version-1 (0)
community: public
data: get-response (2)
get-response
request-id: 383
error-status: noError (0)
error-index: 0
variable-bindings: 1 item
1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2:
Object Name: 1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2 (iso.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2)
Value (Integer32): 20



SnmpGet - utilite
No. Time Source Destination Protocol Info
473 21.019183 192.168.250.110 192.168.2.30 SNMP get-response 1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2

Frame 473: 100 bytes on wire (800 bits), 100 bytes captured (800 bits)
Ethernet II, Src: Cisco_d0:e6:d1 (00:0c:85:d0:e6:d1), Dst: AsustekC_c2:a9:52 (00:26:18:c2:a9:52)
Internet Protocol, Src: 192.168.250.110 (192.168.250.110), Dst: 192.168.2.30 (192.168.2.30)
User Datagram Protocol, Src Port: snmp (161), Dst Port: 49449 (49449)
Simple Network Management Protocol
version: version-1 (0)
community: public
data: get-response (2)
get-response
request-id: 1278
error-status: noError (0)
error-index: 0
variable-bindings: 1 item
1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2:
Object Name: 1.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2 (iso.3.6.1.4.1.318.1.1.14.6.2.1.3.1.2)
Value (Integer32): 31
KS-Soft
Posts: 12821
Joined: Wed Apr 03, 2002 6:00 pm
Location: USA
Contact:

Post by KS-Soft »

Do you mean your device provides different results to exactly the same request?

Regards
Alex
glitchsys
Posts: 1
Joined: Wed Mar 23, 2011 12:15 pm

Known Issue

Post by glitchsys »

I myself discovered this bug with SNMP and the RARU about 3 months ago. It seems if you do an SNMPWALK you get all the results and they're normal. But if you do an SNMPGET for a specific value, it comes out wrong. If you do a bulk walk it's no problem, it's only when you grab specific items does it come out wrong. After an hour or two on the phone with a tech support person to show this issue to them, 24 hours later I get an email from their tech support saying their engineer's could reproduce the issue in the lab and that they'd put a fix out for it in the next firmware release. That was 3 months ago. It seems crazy that there'd be a big bug with SNMP like this, I mean who wouldn't want to monitor their rack temperature sensors and maybe the fan RPM speeds to ensure all the fans are fine and not being slowed down. Waiting on APC to let me know when the next firmware will be released, the current one is from 2007
Post Reply