On 31/01/2008, Manfred Wassmann <[EMAIL PROTECTED]> wrote: > For the error checking I recognized that the set command also returns > the value being set. So in case of an error I would set the > versionNumber to zeroes and the versionState to invalid and return > that value.
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). > The manager would be responsible to check if a version is > available so the agent just has to make a simple plausibility check (if > the major version is the same as the current major or, at least, not > smaller). What the manager *should* do, and what the manager *actually* does is not necessarily the same thing. Plus what if the version seems to be available as far as the manager is concerned, but is not actually accessible to the agent box? (E.g. the TFTP server is down, or the firewall configuration is blocking access, or there's no route from the managed box to the relevant server, etc, etc). > 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). 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. I'm not saying that you *should* do this - you know your customers better than I do, and can tell whether this is a facility that they would expect/want. 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... Dave ------------------------------------------------------------------------- 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 [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
