AP7902 and SNMP oid issues

[Anonymous user]

I recently ran into an issue with a handful of AP7902's and an SNMP script I use to manage them and I was wondering if anyone had any ideas...

Basically, I have a PHP script that uses snmpset to send either a "1", "2" or "3" integer to oid 318.1.1.4.4.2.1.3.[outlet number] -so the end result looks something like this:

snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.08 i 2

However, I've noticed on some of my PDU's this returns an invalid oid error and I can only get it to work if I drop the leading "0" from the outlet number, ex:

snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.08 i 2
Unknown Object Identifier (Sub-id not found: iso -> 08)
snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.8 i 2
SNMPv2-SMI::enterprises.318.1.1.4.4.2.1.3.8 = INTEGER: 2

My other PDU's don't seem to make this distinction. I can send a request to either "8" or "08" and it works. This is the preferred behavior.

Is there any way I can get these PDU's to not make a distinction between port "x" and port "xx"? Or at least be consistent in always expecting "xx"? Am I missing something?

The AP7902 PDU that accepts either a single digit or two digit port number is running:

Network Management Card AOS v2.2.7
Rack PDU APP v2.2.0

The AP7902 PDU that only accepts single digit numbers for certain ports is running:

Network Management Card AOS v2.6.4
Rack PDU APP v2.6.5

Thanks.

[Anonymous user]

Thanks for the reply. At first, I thought I might be able to get around this by downgrading the FW -just like you suggested. In fact, the PDU in question was running a recent version of the AOS until I downgraded it to 2.6.4. The reason I didn't go down to 2.2.7 (the version on the PDU that is working) is because it looks like APC has discontinued this version and I can't find a copy anywhere.

I also thought about modifying the PHP script to send single digits -but this is where it gets weird... some ports on the same PDU insist on being called by "x" while others insist on "0x"... and still others are okay with either format! That's what I meant about consistency... different ports seem to require different formats on the same PDU... and I'm not sure how to make my script "smart enough" to know when it needs to differentiate between the two formats.

For example:

snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.06 i 1
SNMPv2-SMI::enterprises.318.1.1.4.4.2.1.3.6 = INTEGER: 1

snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.6 i 1
SNMPv2-SMI::enterprises.318.1.1.4.4.2.1.3.6 = INTEGER: 1

snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.08 i 1
1.3.6.1.4.1.318.1.1.4.4.2.1.3.08: Unknown Object Identifier (Sub-id not found: iso -> 08)

snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.8 i 1
SNMPv2-SMI::enterprises.318.1.1.4.4.2.1.3.8 = INTEGER: 1

Notice how port 6 is okay with either format -while port 8 requires a single digit.

For what it's worth -the PDU that seems to be functioning properly is running MB:v3.6.4 and the PDU that is giving me troubles is running MB:v3.6.8. I'm under the impression that this is the MIB DB revision number, but I'm not sure how to step this down... I thought this was usually changed whenever you update the AOS, but I could be wrong.

... any help? This is driving me crazy.

Message was edited by: vuduchikin

[Anonymous user]

They have the firmware available on the FTP site 220/227:

ftp://ftp.apcc.com/apc/public/hardware/mswitch/firmware/rpdu/v220/

I would try downgrading the firmware, this should change your MB version on the PDU to the rev. that you allows you to perform your gets/sets properly.

Another thing to try would be the latest revisions of the firmware. There is currently a release of 3.5.5/3.5.6 available to attempt. If you have global outlets enabled, disable them before upgrading and while using this revision of firmware. Another release is expected to be out soon that will address that issue.

It doesn't sounds like a configuration issue on the PDU, but you could try resetting the card to defaults except it's IP settings to rule something of that nature out.

Let us know if the firmware downgrade or upgrade fixes the issue.

Message was edited by: Grenade

[Anonymous user · Accepted solution]

I recently ran into an issue with a handful of AP7902's and an SNMP script I use to manage them and I was wondering if anyone had any ideas...

Basically, I have a PHP script that uses snmpset to send either a "1", "2" or "3" integer to oid 318.1.1.4.4.2.1.3.[outlet number] -so the end result looks something like this:

snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.08 i 2

However, I've noticed on some of my PDU's this returns an invalid oid error and I can only get it to work if I drop the leading "0" from the outlet number, ex:

snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.08 i 2
Unknown Object Identifier (Sub-id not found: iso -> 08)
snmpset -v1 -c private 10.0.0.2 1.3.6.1.4.1.318.1.1.4.4.2.1.3.8 i 2
SNMPv2-SMI::enterprises.318.1.1.4.4.2.1.3.8 = INTEGER: 2

My other PDU's don't seem to make this distinction. I can send a request to either "8" or "08" and it works. This is the preferred behavior.

Is there any way I can get these PDU's to not make a distinction between port "x" and port "xx"? Or at least be consistent in always expecting "xx"? Am I missing something?

The AP7902 PDU that accepts either a single digit or two digit port number is running:

Network Management Card AOS v2.2.7
Rack PDU APP v2.2.0

The AP7902 PDU that only accepts single digit numbers for certain ports is running:

Network Management Card AOS v2.6.4
Rack PDU APP v2.6.5

Thanks.