Re: [tkined] Bug in Scotty's SNMP agent implementation

Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Mon, 15 Dec 1997 11:00:35 +0100

Heiko Boch <boch@lrc.di.epfl.ch> said:

> rfc2089, sxn 2.1:
>
> The SNMPv2 error status is mapped to an SNMPv1 error-status using
> this table:
>
> SNMPv2 error-status SNMPv1 error-status
> =================== ===================
> [...]
> noAccess noSuchName
> --> notWritable noSuchName
> noCreation noSuchName
> [...]
>
> It appears that your Agent is receiving and responding with SNMPv1 PDUs, but
> the subagent/handler for sysDescr.0 is returning an SNMPv2c error code.

Heiko> Yes, looks like. But since I created the agent (which is
Heiko> implemented using Scotty) with -version SNMPv1 I expected it
Heiko> to return SNMPv1 error codes rather than SNMPv2 ones.

Lets see what the SNMPv1 standard says (RFC 1157, section 4.1.5.):

> Upon receipt of the SetRequest-PDU, the receiving entity responds
> according to any applicable rule in the list below:
>
> (1) If, for any object named in the variable-bindings field,
> the object is not available for set operations in the
> relevant MIB view, then the receiving entity sends to the
> originator of the received message the GetResponse-PDU of
> identical form, except that the value of the error-status
> field is noSuchName, and the value of the error-index
> field is the index of said object name component in the
> received message.
>
> (2) If, for any object named in the variable-bindings field,
> the contents of the value field does not, according to
> the ASN.1 language, manifest a type, length, and value
> that is consistent with that required for the variable,
> then the receiving entity sends to the originator of the
> received message the GetResponse-PDU of identical form,
> except that the value of the error-status field is
> badValue, and the value of the error-index field is the
> index of said object name in the received message.
>
> (3) If the size of the Get Response type message generated as
> described below would exceed a local limitation, then the
> receiving entity sends to the originator of the received
> message the GetResponse-PDU of identical form, except
> that the value of the error-status field is tooBig, and
> the value of the error-index field is zero.
>
> (4) If, for any object named in the variable-bindings field,
> the value of the named object cannot be altered for
> reasons not covered by any of the foregoing rules, then
> the receiving entity sends to the originator of the
> received message the GetResponse-PDU of identical form,
> except that the value of the error-status field is genErr
> and the value of the error-index field is the index of
> said object name component in the received message.
>
> If none of the foregoing rules apply, then for each object named in
> the variable-bindings field of the received message, the
> corresponding value is assigned to the variable. Each variable
> assignment specified by the SetRequest-PDU should be effected as if
> simultaneously set with respect to all other assignments specified in
> the same message.
>
> The receiving entity then sends to the originator of the received
> message the GetResponse-PDU of identical form except that the value
> of the error-status field of the generated message is noError and the
> value of the error-index field is zero.

Bottom line: You should never get a readOnly response from a SNMPv1
agent. The value readOnly is only defined in the ASN.1 definitions but
never used elsewhere in the SNMPv1 standard.
Juergen

-- 
Juergen Schoenwaelder  schoenw@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)
--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.