On Wed, 2005-06-22 at 16:31, Mihir Lala wrote:
> > How would you define a failure?
> > For example, consider:
> >
> > $ snmptranslate .1.3.6.1.2.1.1
> > $ snmptranslate .1.3.6.1.2.1.1.0
> > $ snmptranslate .1.3.6.1.2.1.1.1
> > $ snmptranslate .1.3.6.1.2.1.1.0.1.2.3
> It would be more like a prefix (or subtree) match. If there is a "full"
> translation to of an OID that s given then it's a success else a
> failure.
>
> In your example, a translate for .1.3.6.1.2.1.1 would return a success
> but .1.3.6.1.2.1.1.0 or any of the others would be a failure.
OK - so consider a slightly different set of examples:
$ snmptranslate .1.3.6.1.2.1.1.2
$ snmptranslate .1.3.6.1.2.1.1.2.0
$ snmptranslate .1.3.6.1.2.1.1.2.1
$ snmptranslate .1.3.6.1.2.1.1.2.0.1.2.3
That's the same structure, but working with 'SNMPv2-MIB::sysObjectID'.
According to your definition, all but the first one would count as
failures (since there'd be numeric subidentifiers left over).
But the second OID listed is the one that's actually used in practice
(being the OID of the sysObjectID scalar instance), so it seems a
bit perverse to call that a "failure".
It certainly wouldn't be appropriate as part of the main SNMP library.
> Yes, I could have a handler, but the idea was to leverage the tree that
> is already built using the MIB files and not having to configure OIDs.
>
> On receiving a trap, the application would simply lookup the tree for
> the "snmp_trap_oid" (second varbind in the v2c/v3 notifications) and
> either process or drop the trap based on the the lookup return value.
>
> In this way the only traps that get acknowledged are the ones whose MIB
> files are loaded into the snmptrapd application.
Yup - you could implement that using the existing snmptrapd framework.
Define a default trap handler, called for *all* incoming traps.
That handler should take the trap OID (which is one of the input
parameters), do a read_objid() lookup, and check whether the result
had a trailing numeric subidentifier.
If it does, then return without doing any more processing.
Otherwise, it would continue with whatever acknowledgements, etc
you needed to do.
That's perfectly possible with the current Net-SNMP toolkit. I don't
think you need to add any new APIs.
Dave
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
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
