TUT:snmpset - fenner/net-snmp-wiki-experiment GitHub Wiki
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!