SNMP Set-Request Response PDU
Khanh C Nguyen
Does anyone out there look at the data returned from a SNMP SET request?
The Solaris SNMP Master/Subagent scheme doesn't pass data from the agent
to host.
The SNMP definition RFC1448 (ftp://nis.nsf.net/documents/rfc) for the
Set-Request PDU, pg. 25, states:
"At the end of the first phase, if the validation of all variable bindings
succeeded, then:
The value of the Response-PDU's error-status field is set to `noError' and
the value of its error-index field is zero. For each variable binding in
the request, the named variable is created if necessary, and the specified
value is assigned to it."
Currently, should an SNMP Master (in a Master/SubAgent scheme) pass each
variable binding in the Set Request Response PDU with it's value to the
host that requested the SNMP set? (Note that both Windows NT and NetWare
support the transfer of data from agent to host.) If the answer is NO,
then any changes made by the SNMP agent to the variable bindings are lost
and never received by the host.
Regards,
Khanh C. Nguyen kng...@cs.ucf.edu
:::::::::::::::::::::::::::::::::::::::::::::::::::
: Sometimes the Struggle is more important then :
: the Result. Forget not who we are nor what we :
: once were. The possibilities are endless. :
: Train On. Peace my friend. :
:::::::::::::::::::::::::::::::::::::::::::::::::::
Juergen Schoenwaelder
Khanh C Nguyen (kcn4...@pegasus.cc.ucf.edu) wrote:
: The SNMP definition RFC1448 (ftp://nis.nsf.net/documents/rfc) for the
: Set-Request PDU, pg. 25, states:
Note that RFC 1448 is historic. (See the latest SimpleTimes issue
(http://www.simple-times.org/) for an up-to-date description of the
various SNMP versions.)
: "At the end of the first phase, if the validation of all variable bindings
: succeeded, then:
: The value of the Response-PDU's error-status field is set to `noError' and
: the value of its error-index field is zero. For each variable binding in
: the request, the named variable is created if necessary, and the specified
: value is assigned to it."
RFC 1905, section 4.2.5 says:
> Otherwise, the receiving SNMPv2 entity processes each variable
> binding in the variable-binding list to produce a Response-PDU. All
> fields of the Response-PDU have the same values as the corresponding
> fields of the received request except as indicated below.
This is very clear. The agent (whether it is a monolithic or an extensible
agent does not matter) must send a response with the same varbinds. The
second part of your questions is whether the varbind list should contain
the actual values or the values from the set-request PDU. This question
is not clearly answered in RFC 1905. My interpretation of RFC 1905 is that
the agent sends back the values received in the set-request PDU.
Hope this helps,
Juergen
--
Juergen Schoenwaelder sch...@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283)
Mark Lo Chiano
kcn4...@pegasus.cc.ucf.edu (Khanh C Nguyen) wrote:
>Does anyone out there look at the data returned from a SNMP SET request?
>The Solaris SNMP Master/Subagent scheme doesn't pass data from the agent
>to host.
>
>The SNMP definition RFC1448 (ftp://nis.nsf.net/documents/rfc) for the
>Set-Request PDU, pg. 25, states:
>
>"At the end of the first phase, if the validation of all variable bindings
>succeeded, then:
>The value of the Response-PDU's error-status field is set to `noError' and
>the value of its error-index field is zero. For each variable binding in
>the request, the named variable is created if necessary, and the specified
>value is assigned to it."
>
>Currently, should an SNMP Master (in a Master/SubAgent scheme) pass each
>variable binding in the Set Request Response PDU with it's value to the
>host that requested the SNMP set? (Note that both Windows NT and NetWare
>support the transfer of data from agent to host.) If the answer is NO,
>then any changes made by the SNMP agent to the variable bindings are lost
>and never received by the host.
>
>
>Regards,
> Khanh C. Nguyen kng...@cs.ucf.edu
>
>:::::::::::::::::::::::::::::::::::::::::::::::::::
>: Sometimes the Struggle is more important then :
>: the Result. Forget not who we are nor what we :
>: once were. The possibilities are endless. :
>: Train On. Peace my friend. :
>:::::::::::::::::::::::::::::::::::::::::::::::::::
If this is truly the behavior of the Solaris Master, then it is seriously
broken. In SNMP a SET request from a Management station is just that -- a
request for an existing value to be changed -- with a suggestion as to what
the new value should be.
It is up to the remote agent ( in this case, the subagent) to validate
the suggested value. It may:
1. reject the value and return a error.
2. totally accept the value -- and return a response that contains the
"suggested" value.
3. substitute a new appropriate value -- and return a response that
contains the "official" value.
In the last two cases, the management station would need to harvest
the returned values to properly determine the current state of the remote
device.
Respectfully,
Mark Lo Chiano
President
Center Technology
16051 Addision Road, Suite 212
Dallas, Texas 75248
Voice: (01) 972-503-6313
Mobile: (01) 972-345-0029
Email: mailto:MarkLo...@centertechnology.com
Web: http://www.centertechnology.com
Olivier Miakinen
Mark Lo Chiano wrote:
|>
|> If this is truly the behavior of the Solaris Master, then it is
seriously
|> broken. In SNMP a SET request from a Management station is just that
-- a
|> request for an existing value to be changed -- with a suggestion as
to what
|> the new value should be.
|>
|> It is up to the remote agent ( in this case, the subagent) to
validate
|> the suggested value. It may:
|> 1. reject the value and return a error.
|> 2. totally accept the value -- and return a response that contains
the
|> "suggested" value.
|> 3. substitute a new appropriate value -- and return a response that
|> contains the "official" value.
|>
|> In the last two cases, the management station would need to harvest
|> the returned values to properly determine the current state of the
remote
|> device.
Do you mean (3) that the values returned in the Response PDU could be
different to those in the SET Request ? I thought it was impossible
to do that.
--
\\|//
+---------------------------oOO--(o o)-----------------------------+
| mailto:O.Mia...@frcl.bull.fr (_) http://www.openmaster.com |
+--------------------------------------OOo-------------------------+
Michael Landman
Mark Lo Chiano wrote in message <34b3c775.350542026@centechXmain>...
>kcn4...@pegasus.cc.ucf.edu (Khanh C Nguyen) wrote:
>
>>Does anyone out there look at the data returned from a SNMP SET request?
>>The Solaris SNMP Master/Subagent scheme doesn't pass data from the agent
>>to host.
In addition to the other responses to your question already on the list, it
might be helpful to know that the response generated [assuming no error] is
a "get-response" frame, exactly the same frame you would expect to receive
if you had just thrown a "SNMP-GET" frame at an agent. i.e. -- there is
really no such thing as a "snmp-set-response" -- it's just a "get-response"
Of course, I'm also not too familiar with SNMP V2 quite yet and what I'm
discussing applies to SNMP V1.
Mark Lo Chiano
Olivier Miakinen <O.Mia...@frcl.bull.fr> wrote:
It is legal for an agent to modify the operator's set request -- in most
cases. It is also legal for the agent to reject the request with the
appropriate error.
Example: an agent that supports Frame Relay could be designed with
an oid that allows the customer to set a new CIR for a particular circuit.
In the MIB this oid would need to support the full range of possible values
for any frame relay circuit. So this introduces one range of limits that
this oid may assume. (Range A)
However, the customer may not have "purchased" the right to have a FR
circuit with a CIR above 50% of this maximum. This introduces another
range of limits the oid may assume. (Range B).
if this particular customer issues a set request with a value greater than
range B (but less than range A), it is legal for the agent to return either
an error (perhaps Bad Value), or to accept the request, clip it to the
Range B limit, and return the Range B value.
It is up to the agent developer to design an agent which accomplishes the
defined organizational goal, and also complies with the SNMP
specifications. There is a wide degree of freedom in the specifications.
David T. Perkins
HI,
The advice given below by Mark Lo Chiano is incorrect.
A value specified in a SET request must be used as is, or
an error returned. There is no case where an agent may
change the value and return a different value in the
response. Section 4.1.5 of RFC 1157 (SNMPv1 protocol) and
section 4.2.5 of RFC 1905 (SNMPv2 protocol) are quite
clear in their description of how the SET operation works.
The description of the SET operation by Mark Lo Chiano is
inconsistent with that described in the RFCs.
In the example given, the SET operation must return
an error (and not change the value) so that the management
application will know that the value was not changed to
that specified in the request.
Regards,
/david t. perkins
Khanh C Nguyen
Mark Lo Chiano (MarkLo...@centertechnology.com) wrote:
: It is legal for an agent to modify the operator's set request -- in most
: cases. It is also legal for the agent to reject the request with the
: appropriate error.
I agree with Mr. Chiano. The SET Response PDU *may* contain modified data
caused by the Agent. Would someone else please confirm or deny this
topic? Thank you very much!
David T. Perkins
HI
On the following, why do you believe that an agent with the SNMP protocol
specifications can modify the contents of the VARBIND fields in the
response to a SET request?
On 19 Jan 1998, Khanh C Nguyen wrote:
> Mark Lo Chiano (MarkLo...@centertechnology.com) wrote:
>
> : It is legal for an agent to modify the operator's set request -- in most
> : cases. It is also legal for the agent to reject the request with the
> : appropriate error.
>
> I agree with Mr. Chiano. The SET Response PDU *may* contain modified data
> caused by the Agent. Would someone else please confirm or deny this
> topic? Thank you very much!
>
> Regards,
> Khanh C. Nguyen kng...@cs.ucf.edu
Regards,
/david t. perkins
Khanh C Nguyen
>HI
>On the following, why do you believe that an agent with the SNMP protocol
>specifications can modify the contents of the VARBIND fields in the
>response to a SET request?
It's a little hard for me to justify, but let me wave my arms on the
RFC1488 (at ftp://nis.nsf.net/documents/rfc).
Beginning on page 25:
At the end of the first phase, if the validation of all
variable bindings succeeded, then:
The value of the Response-PDU's error-status field is set to
`noError' and the value of its error-index field is zero.
For each variable binding in the request, the named variable
is created if necessary, and the specified value is assigned
to it. Each of these variable assignments occurs as if
simultaneously with respect to all other assignments specified
in the same request. However, if the same variable is named
more than once in a single request, with different associated
values, then the actual assignment made to that variable is
implementation-specific.
Well, the interpretation of "the specified value is assigned to it"
doesn't really *say* for or against. If for some reason there are TWO of
the same variables, then "actual assignment made to that variable is
implementation-specific" definitely implies that the Agent may *modify*
the variable bindings.
If you read on, the RFC doesn't support nor reject the modification of the
variable bindings:
If any of these assignments fail (even after all the previous
validations), then all other assignments are undone, and the
Response-PDU is modified to have the value of its error-status
field set to `commitFailed', and the value of its error-index
field set to the index of the failed variable binding.
If and only if it is not possible to undo all the assignments,
then the Response-PDU is modified to have the value of its
error-status field set to `undoFailed', and the value of its
error-index field is set to zero. Note that implementations
are strongly encouraged to take all possible measures to avoid
use of either `commitFailed' or `undoFailed' - these two
error-status codes are not to be taken as license to take the
easy way out in an implementation.
Finally, the generated Response-PDU is encapsulated into a
message, and transmitted to the originator of the SetRequest-
PDU.
There's my hand waving. Logically, the statements that Mr. Mark Lo
Chiano made make sense to me. Quite frankly, that's what I used it for
for the past 2.5 years. (Wouldn't it be more powerful and useful instead
of getting a failed response specifying the index of the *bad* variable
binding, having to perform a *get* command to figure out what's wrong or
the valid range, etc.,and all this assuming the MIB developer has a get
command(s) that accounted for all the possible reasons for a failed set
command? :)
Now, how about your thoughts?
Regards,
Khanh C. Nguyen kng...@cs.ucf.edu
:::::::::::::::::::::::::::::::::::::::::::::::::::
Mark Lo Chiano
"David T. Perkins" <snmp...@shell5.ba.best.com> wrote:
>HI,
>
>The advice given below by Mark Lo Chiano is incorrect.
>
>A value specified in a SET request must be used as is, or
>an error returned. There is no case where an agent may
>change the value and return a different value in the
>response. Section 4.1.5 of RFC 1157 (SNMPv1 protocol) and
>section 4.2.5 of RFC 1905 (SNMPv2 protocol) are quite
>clear in their description of how the SET operation works.
>
>The description of the SET operation by Mark Lo Chiano is
>inconsistent with that described in the RFCs.
>In the example given, the SET operation must return
>an error (and not change the value) so that the management
>application will know that the value was not changed to
>that specified in the request.
>
You are right, I am wrong. I have been reading this section of the
specifications incorrectly. Sorry for leading everyone in the wrong
direction.
David T. Perkins
HI
On your response, RFC 1488 has nothing to do with SNMP. Did you mean
RFC 1905, starting at the end of page 20? The key paragraph is the
following from section 4.2.5 of RFC 1905:
[The text before this paragraph describes the situation when a
response is too big, and in this case a response is set back
an empty list of varBind items. Now the paragraph that I've
extracted directly explains what to do if the response is
not going to be too big.]
Otherwise, the receiving SNMPv2 entity processes each variable
binding in the variable-binding list to produce a Response-PDU. All
fields of the Response-PDU have the same values as the corresponding
fields of the received request except as indicated below.
[The text that follows describes processing of the varBinds. The
exceptions noted in the above paragraph are changes to the
error-status and error-index fields from a value of zero.
There are no descriptions of changing the values of any other
fields.]
In the text that you have quoted, it describes what should be done
if the same variable is specified twice in the varBind list with
different values. The text that you have quoted says that the agent
may choose either value value.
The addtional text that you quoted seem to have nothinng to do with
the issue of an agent changing the value that is SET or changing
the value of any item in the varBindList.
The description provided by Mark Lo Chiano may seem nice, but they
are not supported by the protocol definition. They are also not
supported by commercial SNMP agent toolkits.
What is the source for the SNMP agents that you have used that
has the behavior that you describe?
On 19 Jan 1998, Khanh C Nguyen wrote:
Regards,
/david t. perkins
u2con
On Mon, 19 Jan 1998, David T. Perkins wrote:
> In the text that you have quoted, it describes what should be done
> if the same variable is specified twice in the varBind list with
> different values. The text that you have quoted says that the agent
> may choose either value value.
Hi David. I guess RFC1905 obsoletes RFC1488.
Thanks for setting me/us straight regarding the set-response PDU.
It may seem like I'm not entirely convinced -but I just wanted to close
this other hole -and then I'll have to thank you again!
Let me continue w/ a question pertaining to the above... If it is true
that the agent "may choose either value" (RFC1905 top pg. 21)
-then does that imply the following:
(1) The data chosen by the "implementation-specific" agent must be in the
Set Response PDU. As a result, in a Master-SubAgent SNMP architecture,
the Master Agent must properly format the Set Response PDU as the SubAgent
specified.
(2) Continuing w/ (1): If (1) is true, then, for a *successful case*, a
Master Agent implementation which ignores the actual variable binding
value done in (1) and just sends a Response PDU with the same values as
the corresponding values of the received request is not fulfulling it's
duty.
In other words, the Master Agent must prepare a Set response PDU as
specfied by the Sub Agent. In turn, the Sub Agent must abide by the Set
Response protocol operations. Only in the case of the following may the
Sub Agent choose a value:
"if the same variable is named more than once in a single
request, with different associated values, then the actual assignment
made to that variable is implementation-specific."
Thank you very much for help!
Regards,
Khanh C. Nguyen kng...@cs.ucf.edu
:::::::::::::::::::::::::::::::::::::::::::::::::::
David T. Perkins
HI,
In the situation where a management application has a SET request
with the same variable in two different varBinds, but with different
values, the management application is broken! The SNMP protocol
spec deals with this "garbage in" case by saying that the agent is
free to do what it wants ("garbage out"). And the spec says that the
varBindList is not modified, so, the management app can not tell
which value was used. But the management app was broken, since
it asked the agent to change a object to two different values
in the same request. What happens here is really not important.
Regards,
/david t. perkins
Greg Barron
kcn4...@pegasus.cc.ucf.edu (Khanh C Nguyen) writes:
>On Mon, 19 Jan 1998 10:34:18 -0800 (PST)
>"David T. Perkins" <snmp...@best.com> wrote:
>>HI
>Well, the interpretation of "the specified value is assigned to it"
>doesn't really *say* for or against. If for some reason there are TWO of
>the same variables, then "actual assignment made to that variable is
>implementation-specific" definitely implies that the Agent may *modify*
>the variable bindings.
The way I read this is if you try to set object "fred" to 678 and also
123 in the same set request, then it is implementation specific as to wether
the fred is set to 678 or 123. It would not set it to some unknown value.
>There's my hand waving. Logically, the statements that Mr. Mark Lo
>Chiano made make sense to me. Quite frankly, that's what I used it for
>for the past 2.5 years. (Wouldn't it be more powerful and useful instead
>of getting a failed response specifying the index of the *bad* variable
>binding, having to perform a *get* command to figure out what's wrong or
>the valid range, etc.,and all this assuming the MIB developer has a get
>command(s) that accounted for all the possible reasons for a failed set
>command? :)
I think SNMPv2 already has enough error reasons for why a set failed!
__
Greg.
--
Greg
Khanh Nguyen
Alright. Thank you very much for everyone's help, especially Mr. Perkins.
Best wishes to all!
Regards,
Khanh C. Nguyen kng...@cs.ucf.edu
:::::::::::::::::::::::::::::::::::::::::::::::::::