RE: help - SNMP Trap manager registration and deregistrationdynamically...
Mike Ayers
> Sent: Monday, January 18, 2010 7:12 AM
> I Require some help regarding the SNMP trap manager/Trap sinks (IP
> Address/Port No/SNMP version v1 or v2c) Registration and deregistration,
> dynamically(At run time) without restarting the agent.
>
> i.e without specifying the trap managers list in snmpd.conf file.
http://www.ietf.org/rfc/rfc2573.txt
WARNING! Steep learning curve ahead!
Enjoy,
Mike
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Borra, Kishore Babu
Thanks for theInformation, I can understand from this RFC that we have to use the target mib, for to implement the Notification receiver.
But, I want to do this operation, of Adding/removing the Notification receiver (Register/Deregist the trap receiver), without using any of the SNMP-TARGET-MIB procedures. I want know some pointers to the code where this is done(Trap receiver addition and deletion).
Regards,
Kishore
Dave Shield
> But, I want to do this operation, of Adding/removing the Notification receiver
> (Register/Deregist the trap receiver), without using any of the SNMP-TARGET-MIB procedures.
> I want know some pointers to the code where this is done(Trap receiver addition and deletion).
The simplest way to add a trap receiver is probably to mimic the processing
of the config file entries, by calling
netsnmp_config( "trapsink localhost" );
with an appropriate config directive.
To remove *all* notification receivers, call
snmpd_free_trapsinks();
Removing an individual trap receiver is going to be harder, since the
config processing routines aren't designed with that in mind.
And remember this will only work from the main SNMP agent.
It's not possible to manipulate the list of notification receivers
from an AgentX subagent (except by using the Target MIB)
Dave
Borra, Kishore Babu
I had tried the below explained method, in a slightly different way, i.e:-
1. For adding/creating a new trap session, used api - create_trap_session(..), instead of netsnmp_config( "trapsink localhost" );.
2.And Removing the Notification receivers using snmpd_free_trapsinks(), as replied in the below mail.
But the problem here is snmpd_free_trapsinks(), is not removing the Recievers, but create_trap_session(..), works properly.
Could you pls me know, if these two api - netsnmp_config(), create_trap_session(..),behaviours are different, which makes snmpd_free_trapsinks(), works or not.
Thanks in advance.
Regards,
Kishore
Dave Shield
> instead of netsnmp_config( "trapsink localhost" );.
> 2.And Removing the Notification receivers using snmpd_free_trapsinks(), as replied in the below mail.
>
> But the problem here is snmpd_free_trapsinks(), is not removing the Recievers,
> but create_trap_session(..), works properly.
>
> Could you pls me know, if these two api - netsnmp_config(), create_trap_session(..),
> behaviours are different, which makes snmpd_free_trapsinks(), works or not.
You've got the code, and are geared up for testing this - why not try
for yourself?
But checking the code more closely, I suspect that you'll find that
snmpd_free_trapsinks()
won't actually work in either case.
Both "create_trap_session" and the config processing each end up calling an
internal "create_trap_session2()" routine, which has two alternative mechanisms
for setting up trap recipients. One uses an internal linked list, which is what
"snmpd_free_trapsinks()" subsequently removes. But the other uses the callback
mechanism to populate the snmpNotifyTable, via the routine
notifyTable_register_notifications()
And the inverse to this (notifyTable_unregister_notifications()) is
invoked as part of
updating the config files. (See init_snmpNotifyTable())
So you might have better luck if you call "update_config()" instead of
"snmpd_free_trapsinks()".
Try it, and see how you get on.
Borra, Kishore Babu
But I had a basic question in the below context, which is regarding the usage of callback function and linked list.
i.e, when will be the linked list be used and when will be the callback function be used. ?,
Is it any conf file changes to drive the trap destinations addtition and freeing using callback methodology?
Is there any other way to add/delete the trap managers using the linked list ?
However I will also try to refer the code and find out the info, if required.
Regards,
Kishore
-----Original Message-----
From: dave....@googlemail.com [mailto:dave....@googlemail.com] On Behalf Of Dave Shield
Sent: Tuesday, January 19, 2010 8:22 PM
To: Borra, Kishore Babu
Cc: net-snm...@lists.sourceforge.net; Mike Ayers
Subject: Re: help - SNMP Trap manager registration and deregistrationdynamically...
Dave Shield
>
> i.e, when will be the linked list be used and when will be the callback function be used. ?,
The callback mechanism will be used if the agent is configured to
support the snmpNotificationTable.
The linked list will be used if it isn't.
> Is it any conf file changes to drive the trap destinations addtition and freeing using callback methodology?
No.
> However I will also try to refer the code and find out the info, if required.
Please do.
Borra, Kishore Babu
For deregistration-
I had experimented with the below api,s, for Notification reciever deregistration dynamically, using extension mib:-
[
update_config(), free_config() & notifyTable_unregister_notifications(int major, int minor, void *serverarg, void *clientarg)..
]
update_config(), free_config() hasn't worked but luckily notifyTable_unregister_notifications() with input parameters as 0,0,NULL,NULL has worked. (These parameters are not used however in the function body).
This unregisters all the trap/Notification receivers, but don't know if there is any way to remove the selective Trap sessions/receivers.
Also I had basic question about the input parameters getting passed to the notifyTable_unregister_notifications(), .
i..e What are the input parameters major, minor, void *serverarg, void *clientarg serves as ?
and Do we have to pass any valid values for the input args, so that in future it doesn't effect, even if the functionality of this api changes?
Regards,
Kishore
-----Original Message-----
From: dave....@googlemail.com [mailto:dave....@googlemail.com] On Behalf Of Dave Shield
Sent: Tuesday, January 19, 2010 10:10 PM
To: Borra, Kishore Babu
Cc: net-snm...@lists.sourceforge.net; Mike Ayers
Subject: Re: help - SNMP Trap manager registration and deregistrationdynamically...
Dave Shield
> Also I had basic question about the input parameters getting passed to the notifyTable_unregister_notifications(), .
>
> i..e What are the input parameters major, minor, void *serverarg, void *clientarg serves as ?
The first two parameters (major, minor) match those used when registering
the callback. (see snmpNotifyTable). These are used to control when this
particular callback routine will be invoked, and are passed to the callback
routine in case it needs to distinguish between different possible invocations.
It is also possible to supply some arbitrary data as part of this registration
(using the final parameter of the registration call). This is then passed to
the callback routine as the 'clientarg' parameter.
The code that triggers the callback (snmp_call_callbacks) can also provide
some arbitrary data, which is passed to the callback routine as 'serverarg'.
This is used by (e.g.) the access control callbacks, or those concerned with
registering MIB modules.
> Do we have to pass any valid values for the input args, so that in future
> it doesn't effect, even if the functionality of this api changes?
These routines are not designed to be invoked directly.
They are meant to be invoked via 'snmp_call_callbacks'.
If you are invoking notifyTable_unregister_notifications() yourself, then you
will need to monitor any code changes that affect the relevant major/minor
callback values (currently APPLICATION/PRE_UPDATE_CONFIG. But note
that this is not necessrily fixed).
If you are working outside the intended design, then the onus is on you
to watch for changes that might break your code.
Borra, Kishore Babu
Right now Iam using the below api as mentioned, which works fine for UnRegistering all the Notfication receivers.:-
snmp_call_callbacks(SNMP_CALLBACK_APPLICATION,
SNMPD_CALLBACK_PRE_UPDATE_CONFIG, NULL);
Regards,
Kishore
-----Original Message-----
From: dave....@googlemail.com [mailto:dave....@googlemail.com] On Behalf Of Dave Shield
Sent: Thursday, January 21, 2010 6:01 PM
To: Borra, Kishore Babu
Cc: net-snm...@lists.sourceforge.net; Mike Ayers
Subject: Re: help - SNMP Trap manager registration and deregistrationdynamically...
Dave Shield
> Right now Iam using the below api as mentioned, which works fine for UnRegistering all the Notfication receivers.:-
>
> snmp_call_callbacks(SNMP_CALLBACK_APPLICATION,
> SNMPD_CALLBACK_PRE_UPDATE_CONFIG, NULL);
Fair enough.
But bear in mind that this may well affect other MIB modules
as well. It's designed to be called immediately before
re-reading the config files, so will typically drop *all*
snmpd.conf-based settings, for a wide variety of MIB modules.
Invoking the pre-update callback *without* then re-loading the
config files may result in the loss of other settings.