HI,
In the work that I did, I found that the current notification
delivery system (and receiving system) provides VERY little
feedback when there are configuration problems. And configuration
problems are the number one issue in using notifications.
Please think about how you would figure out that you have
a configuration problem ("configruation problem" - 1)what is
configured on one side is not compatible with what is configured
on the other side and BOTH sides have valid configurations, or
2)there is a problem with the configuration (such as the IP
address of the notification target is incorret)). Assume
that there are no coding bugs, and that you do not have
a packet sniffer or other "extra" software or hardware.
How would you determine that
1) the configuration was correct (how would you verify
that notifications would be sent and received) if
a real event occured
2) what was wrong with the configuration (and thus, what
needed to be changed)? Detail the steps
and the decisions based on the feedback that you got.
This is real world. I've got to write up a "white paper" for
the product that I did using what I put in. I've got to do
this because the users can't seem to get this correct, and
they then say that the product is not working correctly.
(And note, there have been bugs found in the product
with the event handling code not generating a notification
or the wrong one. But making sure that the delivery process
is configured correctly is always the first step in
looking at the problem.)
Regards,
/david t. perkins
On Thu, 25 Aug 2005, Dave Shield wrote:
> [Wes - if you're around, we could probably
> do with your input on this one! ]
>
> On Tue, 2005-08-23 at 16:33 -0700, David T. Perkins wrote:
>
> > Now, on NET-SNMP, what I find most troubling is the
> > inconsistent behavior between SNMPv1(and v2c), and
> > SNMPv3/USM, and between TRAPs and INFORMs.
>
> Agreed.
> The current situation is clearly not sensible,
> and should be improved.
>
>
> > I would hope for the following changes for USM:
> > 1) with no users configured, you should be able to recieve
> > both noAuthNoPriv TRAPs and INFORMs
>
> I'd support that.
> It would be consistent with the handling of community-based
> notifications, and also the generation of SNMPv3 noAuth
> requests.
> (see snmpusm.c:usm_generate_out_msg())
>
>
> > 2) on authNoPriv TRAPs and INFORMs, if there is a
> > problem ... then I believe that the notification
> > should still be outputted
>
> I disagree.
> That would be inconsistent with the handling of errors with
> other PDU types, and the processing of community-based traps.
> (e.g RFC 1157, section 4.1)
>
> It might well be sensible to log an indication that there
> was an erroneous message received (rather than just failing
> silently), but I wouldn't suggest any more processing than
> that. It certainly shouldn't be merged with the main trap
> handler processing.
>
>
> > 3) on authPriv and a failure, an output should still
> > be done, but with an error indication that the
> > message content is not available.
>
> Again, this feels similar to the failed authenticated request
> case. Logging an error would be sensible, but nothing more.
>
>
>
>
> >From the other list of suggestions:
> > 1) not require entries for noAuthNoPriv
> Agreed
>
> > 2) print what protocol of each trap or inform
> > 3) print security level (unsecured (noAuthNoPriv),
> > authenticated(authNoPriv), or encrypted(authPriv)
>
> I don't think we should change the existing (external)
> 'traphandle' API. We've documented the input format
> that such scripts should expect for too long now.
> However the internal Netsnmp_Trap_Handler routine does
> receive the incoming PDU (complete with version and
> administrative settings) as one of the parameters.
> So this information is already available to C-based
> trap handlers.
>
> There probably isn't a simple way to make use of this
> as yet (other than adding code to 'snmptrapd_handlers.c'),
> but the basic framework is in place.
> Either extending the build environment to support a
> "trapd module" mechanism (similar to the existing agent
> MIB module setup), or a new "trap2handle" directive
> (with an extended input format). Or both!
>
>
> > 4) print and indication as to the status (success, noSuchUser,
> > engineID/EngineClock discovery, outOfTimeWindow, authFail,
> > decryptionFail, etc)
>
> Reporting errors feels different from processing successful
> incoming requests. I can see a case for having a separate
> "error handler" mechanism, but this should probably be
> considered as part of the main SNMP library, rather than
> something exclusively for snmptrapd.
>
>
>
> I *still* feel that we need to address the non-scalability
> of engine IDs wrt SNMPv3 traps. Both GET*/SET requests
> and inform notifications Just Work (discovering engineIDs
> automatically). That's not possible for unacknowledged
> traps, but we ought to be able to come up with a simpler
> mechanism, but staying within the existing (possibly broken)
> USM framework.
> Hence my suggestion of "wildcard" user matching.
>
>
> Dave
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
