snmpget returns successfully, yet snmpset claims the same OID does not exist

Question

I'm working with a CyberPower PDU: https://www.cyberpowersystems.com/product/pdu/switched-ats/pdu15swhviec12atnet/

According to snmpwalk -v1 -m CyberPower_MIB_v2.9.MIB -c public 10.42.0.2 iso.3.6.1.4.1.3808, the management card model is RMCARD205 and the full model name is PDU15SWHVIEC12ATNET.

I would like to programmatically control the power to the ports, doing this via SNMP seems the most robust option. I can query the status of port 3 (say) with,

# snmpget -v1 -c private 10.42.0.2 iso.3.6.1.4.1.3808.1.1.5.6.3.1.3.3
SNMPv2-SMI::enterprises.3808.1.1.5.6.3.1.3.3 = INTEGER: 2

That is, the OID iso.3.6.1.4.1.3808.1.1.5.6.3.1.3.3 clearly exists and has the value of 2 (which means OFF in this case). Now, let me set it to 1 (meaning ON), with an integer value type (encoded as i in SNMP),

snmpset -v1 -c private 10.42.0.2 iso.3.6.1.4.1.3808.1.1.5.6.3.1.3.3 i 1
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.3808.1.1.5.6.3.1.3.3

I found in this SO question an answer suggesting it's not at all uncommon for these devices to have bugs, but the behaviour was a bit different to what I've got here. Similarly, the SNMP FAQ didn't offer any specific advice on this issue for me.

It seems the above interactions are proof that the device is faulty, but SNMP is sufficiently nuts that I wouldn't be surprised if there's some weird thing I should actually be doing to get this to work.

Please use v2 and it will tell you more on the error itself. SNMP v1 only defines a few error code, so the agent has to return `noSuchName` while the actual error was something else. — Lex Li, Jun 09 '21 at 14:00
I ran with `snmpset -v2c ...` as above, and the error message was the same as with -v1. — Charles, Jun 09 '21 at 16:19
You have to contact the device vendor for further assistance. For example, maybe they don't allow SET operations on such objects, until you make certain changes on the device. That's not something you can learn from a forum like this. — Lex Li, Jun 09 '21 at 16:34

score 0 · Accepted Answer · answered Jun 10 '21 at 13:12

I found the answer to my question and will post some details here, in case others are as confused as I was!

The first tip is to use the device manufacturers MIB files. CyberPower published a single MIB file (which is basically a textual description of all the properties in the hardware devices) that allows the net-snmp tools to print descriptive names for the otherwise opaque OIDs. For example, to see what I was attempting to set above, after downloading the MIB file into the current working directory,

# snmpwalk -v1 -c private -M +.  -m ALL  10.42.0.2 iso.3.6.1.4.1.3808.1.1.5.6.3.1.3
CPS-MIB::atsOutletStatusOutletState.1 = INTEGER: outletStatusOn(1)
CPS-MIB::atsOutletStatusOutletState.2 = INTEGER: outletStatusOn(1)
CPS-MIB::atsOutletStatusOutletState.3 = INTEGER: outletStatusOff(2)
CPS-MIB::atsOutletStatusOutletState.4 = INTEGER: outletStatusOff(2)
CPS-MIB::atsOutletStatusOutletState.5 = INTEGER: outletStatusOn(1)
CPS-MIB::atsOutletStatusOutletState.6 = INTEGER: outletStatusOn(1)
CPS-MIB::atsOutletStatusOutletState.7 = INTEGER: outletStatusOn(1)
CPS-MIB::atsOutletStatusOutletState.8 = INTEGER: outletStatusOn(1)
CPS-MIB::atsOutletStatusOutletState.9 = INTEGER: outletStatusOn(1)
CPS-MIB::atsOutletStatusOutletState.10 = INTEGER: outletStatusOn(1)
CPS-MIB::atsOutletStatusOutletState.11 = INTEGER: outletStatusOn(1)
CPS-MIB::atsOutletStatusOutletState.12 = INTEGER: outletStatusOn(1)

At first this seemed like the right place to change the statuses, but this PDU, unlike others I've encountered, has a separate OID tree for control operations, in addition to the above OID tree for status operations,

# snmpwalk -v1 -c private -M +.  -m ALL  10.42.0.2 iso.3.6.1.4.1.3808.1.1.5.6.5
CPS-MIB::atsOutletCtrlTableIndex.1 = INTEGER: 1
CPS-MIB::atsOutletCtrlTableIndex.2 = INTEGER: 2
CPS-MIB::atsOutletCtrlTableIndex.3 = INTEGER: 3
CPS-MIB::atsOutletCtrlTableIndex.4 = INTEGER: 4
CPS-MIB::atsOutletCtrlTableIndex.5 = INTEGER: 5
CPS-MIB::atsOutletCtrlTableIndex.6 = INTEGER: 6
CPS-MIB::atsOutletCtrlTableIndex.7 = INTEGER: 7
CPS-MIB::atsOutletCtrlTableIndex.8 = INTEGER: 8
CPS-MIB::atsOutletCtrlTableIndex.9 = INTEGER: 9
CPS-MIB::atsOutletCtrlTableIndex.10 = INTEGER: 10
CPS-MIB::atsOutletCtrlTableIndex.11 = INTEGER: 11
CPS-MIB::atsOutletCtrlTableIndex.12 = INTEGER: 12
CPS-MIB::atsOutletCtrlOutletName.1 = STRING: "Outlet1"
CPS-MIB::atsOutletCtrlOutletName.2 = STRING: "Outlet2"
CPS-MIB::atsOutletCtrlOutletName.3 = STRING: "Outlet3"
CPS-MIB::atsOutletCtrlOutletName.4 = STRING: "Outlet4"
CPS-MIB::atsOutletCtrlOutletName.5 = STRING: "Outlet5"
CPS-MIB::atsOutletCtrlOutletName.6 = STRING: "Outlet6"
CPS-MIB::atsOutletCtrlOutletName.7 = STRING: "Outlet7"
CPS-MIB::atsOutletCtrlOutletName.8 = STRING: "Outlet8"
CPS-MIB::atsOutletCtrlOutletName.9 = STRING: "Outlet9"
CPS-MIB::atsOutletCtrlOutletName.10 = STRING: "Outlet10"
CPS-MIB::atsOutletCtrlOutletName.11 = STRING: "Outlet11"
CPS-MIB::atsOutletCtrlOutletName.12 = STRING: "Outlet12"
CPS-MIB::atsOutletCtrlCommand.1 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.2 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.3 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.4 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.5 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.6 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.7 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.8 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.9 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.10 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.11 = INTEGER: none(1)
CPS-MIB::atsOutletCtrlCommand.12 = INTEGER: none(1)

It is the CPS-MIB::atsOutletCtrlCommand tree that can be set, to change the outlet state, by doing the following,

# snmpset -M +. -m ALL -v1 -c private 10.42.0.2 SNMPv2-SMI::enterprises.3808.1.1.5.6.5.1.3.3 i 3
CPS-MIB::atsOutletCtrlCommand.3 = INTEGER: immediateOff(3)

And the port changes state. The state mappings can be found by consulting the MIB file mentioned above (in this reading, a file named CyberPower_MIB_v2.9.MIB). For example, I found the following definitions which helped me learn which integer represents off/on and so on,

...
atsOutletCtrlCommand OBJECT-TYPE
        SYNTAX INTEGER {
            none                                        (1),
            immediateOn                         (2),
            immediateOff                        (3),
            immediateReboot                 (4),
            delayedOn                               (5),
            delayedOff                          (6),
            delayedReboot                       (7),
            cancelPendingCommand        (8)
        }
...

Here, it can be discerned that to turn a port off, it's integer 3, on is 2, and so on.

It remains a mystery to me why the SNMP tools don't give clearer errors (noSuchName is misleading, the name very much does exist, it simply is read-only, but such is life in tech)

SNMP makes a distinction between readonly and writable OIDs, so be sure to look at the "ACCESS" line in a MIB to see whether an OID is defined as "read-only" or "read-write". The atsOutletCtrlCommand OID is defined in the cyberpower MIB as: "ACCESS read-write", as opposed to the atsOutLetStatusOutletState OID which is defined as: atsOutletStatusOutletState OBJECT-TYPE SYNTAX INTEGER { outletStatusOn (1), outletStatusOff (2) } ACCESS read-only -- <== read-only — Will Pierce, Jun 19 '21 at 17:54

snmpget returns successfully, yet snmpset claims the same OID does not exist

1 Answers1