The SET request is used to modify information on the target agent - updating the configuration of that agent, or controlling the behaviour of the remote system. This protocol operation can be sent via the snmpset command line tool.

The syntax of the snmpset command is similar to that of the snmpget command, and most of the snmpget tutorial applies here too. The main difference is in specifying the information to work with. Instead of a single OID, the snmpset command requires the OID to update, the data type of this object, and the new value to apply:

   snmpset -v 1 -c demopublic test.net-snmp.org ucdDemoPublicString.0`` ``s`` ``"hi`` ``there!"

The effect of this command can usually be seen by retrieving the value of an object, both before and after the SET request:

   $ snmpget -v 1 -c demopublic test.net-snmp.org ucdDemoPublicString.0    UCD-DEMO-MIB::ucdDemoPublicString.0 = "hi there!"    $ snmpset -v 1 -c demopublic test.net-snmp.org ucdDemoPublicString.0`` ``s`` ``"Hello,`` ``world!"    UCD-DEMO-MIB::ucdDemoPublicString.0 = "Hello, world!"    $ snmpget -v 1 -c demopublic test.net-snmp.org ucdDemoPublicString.0    UCD-DEMO-MIB::ucdDemoPublicString.0 = "Hello, world!"

Note that the values returned following the SET request will always be the same as those provided. This is normally the same as that returned by a subsequent GET request (as shown above), but not necessarily:

   $ snmpget test.net-snmp.org  snmpSetSerialNo.0    SNMPv2-MIB::snmpSetSerialNo.0 = INTEGER: 123456    $ snmpset test.net-snmp.org  snmpSetSerialNo.0 i 123456    SNMPv2-MIB::snmpSetSerialNo.0 = INTEGER: 123456    $ snmpget test.net-snmp.org  snmpSetSerialNo.0    SNMPv2-MIB::snmpSetSerialNo.0 = INTEGER: 123457

The list of valid datatypes can be found at the end of the snmpset help output:

   $ snmpset -h |& tail -4    type - one of i, u, t, a, o, s, x, d, n      i: INTEGER, u: unsigned INTEGER, t: TIMETICKS, a: IPADDRESS      o: OBJID, s: STRING, x: HEX STRING, d: DECIMAL STRING      U: unsigned int64, I: signed int64, F: float, D: double

Note that the last four types are only valid when talking to the Net-SNMP agent. They are not part of the official SNMP specification.

Assuming that the MIB file is loaded, then it's also possible to specify the type as "=", and the snmpset command will supply the appropriate type from the MIB file:

   $ snmpset test.net-snmp.org ucdDemoPublicString.0 = "Hello clouds"    UCD-DEMO-MIB::ucdDemoPublicString.0 = "Hello clouds"

This doesn't work if the MIB file isn't loaded, of course - but then referring to the MIB object by name wouldn't either!

As with the snmpget command, it also is possible to SET several new values in the one request. Simply specify the list of (OID,type,value) triples on the command line:

   $ snmpset test.net-snmp.org ucdDemoPublicString.0 s "Hello sky"  snmpSetSerialNo.0 i 123457    UCD-DEMO-MIB::ucdDemoPublicString.0 = "Hello sky"    SNMPv2-MIB::snmpSetSerialNo.0 = INTEGER: 123457

If one of these assigments is invalid, then the request will be rejected without applying any of the new values - regardless of the order they appear in the list. This is quite useful for the administrator wanting to manage their systems, but can be something of a headache for the poor schmuck landed with the task of implementing the SET handling within the agent.

If the MIB file has been loaded, and the supplied value is invalid according to the MIB definitions (e.g. the wrong type, or outside the valid range for that object), then snmpset will display a failure message without ever sending the request to the target agent:

   $ snmpset test.net-snmp.org  snmpSetSerialNo.0 s`` ``"as`` ``any`` ``fule`` ``kno"    snmpSetSerialNo.0: Bad`` ``variable`` ``type        (Type of attribute is INTEGER, not OCTET STRING)

If the MIB file is not available, or the value matches the syntax from the MIB definition, then the request will be sent to the target agent which may then reject the request:

   $ snmpset test.net-snmp.org  snmpSetSerialNo.0 i 9999    Error in packet.    Reason: (badValue) The value given has the wrong type or length    Failed object: SNMPv2-MIB::snmpSetSerialNo.0

The same effect can be seen by suppressing the local validation:

   $ snmpset test.net-snmp.org -Ir snmpSetSerialNo.0 s "How To Be Topp"    Error in packet.    Reason: (badValue) The value given has the wrong type or length    Failed object: SNMPv2-MIB::snmpSetSerialNo.0

SNMPv1 reports such problems using a single error report (badValue) as shown above. SNMPv2c is a little more informative:

   $ snmpset -v 2c test.net-snmp.org -Ir snmpSetSerialNo.0 s "uterly wet"    Error in packet.    Reason: (wrongType) The set datatype does not match the data type the agent expects    Failed object: SNMPv2-MIB::snmpSetSerialNo.0    [`` ``]`` ``Actually`` ``returns`` ``wrongValue    $ snmpset -v 2c test.net-snmp.org     snmpSetSerialNo.0 i 9999    Error in packet.    Reason: (wrongValue) The set value is illegal or unsupported in some way    Failed object: SNMPv2-MIB::snmpSetSerialNo.0

Similarly, if you don't have permission to write to an object, the error reported will be different depending on the version of SNMP used:

   $ snmpset -v 1  -c rocommunity test.net-snmp.org  snmpSetSerialNo.0 i 123457    Error in packet.    Reason: (noSuchName) There is no such variable name in this MIB.    Failed object: SNMPv2-MIB::snmpSetSerialNo.0    $ snmpset -v 2c -c rocommunity test.net-snmp.org  snmpSetSerialNo.0 i 123457    Error in packet.    Reason: noAccess    Failed object: SNMPv2-MIB::snmpSetSerialNo.0    [`` ``]`` ``Should`` ``this`` ``return`` ``notWritable``?

SNMPv3 uses the same (improved) error codes as SNMPv2c, as well as providing much better security - which is potentially quite important when it comes to SET requests!

---