[Sorry for the delay in getting back to you on this]

2009/2/4 Rodolfo Leffa <[email protected]>:
> Could you(or other) tell me if there's a way to extend the agent by
> implementing a single module to extend the whole MIB, instead of one for
> which entry in the MIB??

That's a common way of working, yes.
The agent doesn't really care whether you implement a module
that handles one single object, a table, or a whole subtree.
How you structure the code is totally up to you.

In practise, we've found that the most effective approach is
to handle each table or group of scalars individually,
and have separate files for different tables or groups.

But if you've got two tables that are closely linked together
(such as the hrSWRunTable/hrSWRunPerfTable), then
it makes perfect sense to implement them in the one module.
   Similarly for a table plus related scalar (such as a count
of the number of rows, a last-changed timestamp, or a lock object).

Basically, it's totally up to you how you write the code.




> I want to do something like that: snmpget sends my agent a request like this
> - snmpget ... MYMIB::MIBDATA.1.0.22.1 .  When it gets to the agent, it would
> repass it to my extending module(MIBDATA). Inside the handler then I can get
> the rest of the requisition( 1.0.22.1) and choose wich data is being
> requested.  Is it possible??

That's certainly possible.
Just use the generic "netsnmp_register_handler()" call, instead of
one of the more specific helper registrations.

The advantage of the table-based helpers is that they take care of
extracting and interpreting the table index for you automatically.
But if that isn't something you need, then you can always deal
with this yourself.

Dave

------------------------------------------------------------------------------
_______________________________________________
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

Reply via email to