On 9/5/07, Wes Hardaker <wjhns36@xxxxxxxxxxxxx> wrote:
> >>>>> "LEO" == Luis EG Ontanon <luis.ontanon@xxxxxxxxx> writes:
>
> LEO> I went to libsmi mainly because I could not find any documentation on
> LEO> how to traverse the already loaded MIB in Net-SNMP.
>
> Ah. It's certainly possible, just FYI, since
> net-snmp/apps/snmptranslate traverses the loaded MIBs to display the
> results in all sorts of output formats.
I guess it is but after some time looking in net-snmp includes I found
not an API way to do so.
> But anyway, libsmi is designed to be a library to do what you want so
> it's a great choice too (I've used it numerous times to build things
> with as well).
It's tailored to do it, it misses the ability to add modules and nodes
from the API and to give the set some userdata for the nodes, so I
had to build the data structures or the OIDs myself.
> One comment, just for thought... I'd make sure you define you filter
> expression carefully so you can distinguish what part is a MIB and what
> is an object. That way when you get an unknown component, you can
> recognize and possibly try to load it (even ask for a path, if you're
> braving the dialog box world as well). IE:
Fields are registered in the startup phase, all oids that are to
become fields have to be known during protocol registration.
> IF-MIB.ifEntry.ifIndex == 3
>
> Is the MIB name always required to be first? (Net-SNMP's API is very
> flexible and could handle just ifIndex == 3 if the IF-MIB was
> pre-loaded)
Just ifIndex does not denote where it comes from, it would be
confusing to have hundreds of "orphan" fields.
> Common MIB syntax, by the way, which is understood by many operators is
> IF-MIB::ifIndex == 3
Field names cannot take ':'. If I try to change this the dfilter
scanner could do weird things) so the filter name uses '.' instead (as
all other filter fileds). In the display of the protocol tree the
fields use "::".
Luis
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan