On Fri, 1 Feb 2008, Dave Shield wrote:
> On 31/01/2008, Manfred Wassmann <[EMAIL PROTECTED]> wrote:
[...]
> No - you can't do that.
> The value returned *MUST* be the same as the value that was
> being set. That's part of the SNMP specs.
> You can return an error value as part of the SNMP response,
> but this takes a limited range of values (and again, the specs
> are fairly precise about what errors are returned when).
OK, returning to the specs I read RFC 3416 section 4.2.5:
"All fields of the Response-PDU have the same values as the
corresponding fields of the received request except as indicated
below."
That's definite, but it looks like I can return one of the errors
listed in steps 6 and 10 to 12 of the validations performed when
processing the variable bindings of a SetRequest-PDU.
(6) "wrongValue", if the version specified is invalid (but not simply
not available).
(10) "inconsistentValue", if the version specified is not appropriate
(or not available in case I download immediately).
(11) "resourceUnavailable", if the download fails.
(12) "genErr" on other errors, if any.
>> If the version specified is not available when the update is performed the
>> update will just fail. The manager can check for a failed update by
>> checking the currentVersion OID.
>
> That would allow the manager to detect that the upload has failed.
> Similarly, you could probably return an error to this effect as part
> of processing the SET request (assuming that the upload is applied
> immediately and you're happy to wait for this to complete before
> sending the SNMP response).
It looks like a good idea to have the device trying to download the
version while processing the set request. But the manager would need to
specify a fairly long timeout with the set command and I should
probably note that fact in the relevant DESCRIPTION clause?
> But if you wanted to provide some indication of *why* the upload
> failed (couldn't contact the server, the server said no, which
> server should I use anyway, etc), then you might need to provide
> a separate MIB object to report this information.
This also looks like a good idea.
> Primarily I'm trying to get you to think about these sorts of issues,
> and (particularly) to document them in the DESCRIPTION clauses.
> Remember, if you get hit by a bus tomorrow, then the descriptions
> in the MIB file are all that your successor will have to work on when
> they have to pick up where you left off.
>
> Think of this as the design spec for your SNMP interface.
> Try to include the same level of detail as you'd need to put into a
> formal program design document in order to keep the suits upstairs
> happy. Well, maybe not quite that much, but you get the idea...
Thanks for your advice, I thought I had been fairly elaborate when
writing the MIB text but now I see I have missed a lot.
Manfred
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
