Difference between revisions of "Template:FAQ:Applications 12"
Line 24: | Line 24: | ||
Similarly, the SNMPv2 error <CODE>'notWritable'</CODE> means "not writable in | Similarly, the SNMPv2 error <CODE>'notWritable'</CODE> means "not writable in | ||
this particular case" rather than "not writable under any circumstances". | this particular case" rather than "not writable under any circumstances". | ||
+ | |||
+ | If you are sure that the object is writable (and has been implemented | ||
+ | as such), then you probably need to look at the agent access control. | ||
+ | See the AGENT section for more details. |
Revision as of 21:41, 20 October 2006
This is actually the same as the previous question - it just isn't particularly obvious, particularly when using SNMPv1. A typical example of this effect would be
$ snmpget -v1 -c public localhost system.sysLocation.0 system.sysLocation.0 = somewhere nearby
$ snmpset -v1 -c public localhost system.sysLocation.0 s "right here" Error in packet. Reason: (noSuchName) There is no such variable name in this MIB. This name doesn't exist: system.sysLocation.0
Trying the same request using SNMPv2 or above is somewhat more informative:
$ snmpset -v 2c -c public localhost system.sysLocation.0 s "right here" Error in packet. Reason: notWritable
The SNMPv1 error 'noSuchName'
actually means: "You can't do that to this variable"
This might be because the variable doesn't exist, it does exist but
you don't have access to it (but someone else may do), or it exists
but you can't perform that particular operation (i.e. changing it).
Similarly, the SNMPv2 error 'notWritable'
means "not writable in
this particular case" rather than "not writable under any circumstances".
If you are sure that the object is writable (and has been implemented as such), then you probably need to look at the agent access control. See the AGENT section for more details.