View previous topic :: View next topic |
Author |
Message |
ksn
Joined: 07 Sep 2010 Posts: 3
|
Posted: Tue Sep 07, 2010 2:44 am Post subject: Temperature SNMP Get test |
|
|
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. |
|
Back to top |
|
|
KS-Soft
Joined: 03 Apr 2002 Posts: 12807 Location: USA
|
Posted: Tue Sep 07, 2010 11:07 am Post subject: |
|
|
Can we get access to your device?
Regards
Alex |
|
Back to top |
|
|
ksn
Joined: 07 Sep 2010 Posts: 3
|
Posted: Tue Sep 07, 2010 11:29 pm Post subject: |
|
|
yes, on your mail. |
|
Back to top |
|
|
KS-Soft
Joined: 03 Apr 2002 Posts: 12807 Location: USA
|
Posted: Wed Sep 08, 2010 10:38 am Post subject: |
|
|
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 |
|
Back to top |
|
|
ksn
Joined: 07 Sep 2010 Posts: 3
|
Posted: Thu Sep 09, 2010 1:27 am Post subject: |
|
|
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 |
|
Back to top |
|
|
KS-Soft
Joined: 03 Apr 2002 Posts: 12807 Location: USA
|
Posted: Thu Sep 09, 2010 11:50 am Post subject: |
|
|
Do you mean your device provides different results to exactly the same request?
Regards
Alex |
|
Back to top |
|
|
glitchsys
Joined: 23 Mar 2011 Posts: 1
|
Posted: Wed Mar 23, 2011 12:18 pm Post subject: Known Issue |
|
|
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 |
|
Back to top |
|
|
|