One other possibility: split targetAddrTable_struct's session pointer into one for traps and one for informs, configure the trap one with the agent's engineID, and add whichever one (or both) to the result that's appropriate. Needs to still not create multiple sessions for the same notification type (per patch 1637287), though, unless storage and result are split to not step on each other.
-- Michael Kirkham President & CEO Muonics, Inc. http://www.muonics.com/ On Tue, 23 Jan 2007, Michael Kirkham wrote: > Date: Tue, 23 Jan 2007 03:15:42 -0800 (PST) > From: Michael Kirkham <[EMAIL PROTECTED]> > To: [email protected] > Subject: Re: Failed sending V3 traps with auth using snmpNotifyTable > > > Having been digging for bugs in the target/notification/filter table > mechanisms, I can confirm this. > > When it's time to send notifications to targets registered via the MIB > tables, the agent calls send_notifications (snmpNotifyTagble.c). > > send_notifications calls get_target_sessions (target.c) to get (and create, > if not yet done) sessions for targets matching snmpNotifyTag values. > > get_target_sessions calls snmp_add (snmp_api.c). > > snmp_add calls snmp_sess_add_ex (snmp_api.c). > > snmp_sess_add_ex automatically probes if the session version is SNMPv3, > though it's not determined yet what kind of notification will be sent. > > send_notifications calls send_trap_to_sess (agent_trap.c). > > send_trap_to_sess calls snmp_send and finds its way to _sess_async_send > (snmp_api.c). > > _sess_async_send doesn't do anything about the session's engine ID > because no response is expected. > > Looks like it winds up in snmpv3_build (snmp_api.c) from there, > which just uses the Engine ID from the session. > > I'm kind of thinking that get_target_sessions ought to create one > session per tag after all if it's going to use the cached engine ID > in this way, because even if you skip probing at creation until > you know you're going to send an inform to the target, the target > could actually have been configured to send both a trap and an > inform (by listing two snmpNotifyTag values - one for each). > > Otherwise, perhaps send_trap_to_sess ought to figure out which to > use based on notification type, or something. Maybe a session > flag set in get_target_sessions that tells it to? > >> The patch you sent me is about a problem with using the config file >> directive 'trapsess', >> I'm not using that, I'm using the snmpTargetMIB and snmpNotificationMIB >> to send traps. >> >> Erez. >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Dave Shield >> Sent: Friday, January 19, 2007 11:33 AM >> To: Makavy, Erez (Erez) >> Cc: [EMAIL PROTECTED] >> Subject: Re: Failed sending V3 traps with auth using snmpNotifyTable >> >> On 18/01/07, Makavy, Erez (Erez) <[EMAIL PROTECTED]> wrote: >> > When I define a trap manager assigned with a local-user (user which >> > has the engine id of the local agent, not the engine id of the >> > management station), I can not send out notifications with >> > authentication (without authentication works fine). >> >> Known problem - fixed in 5.4 and the current CVS code for earlier >> branches. >> >> >> > Could you point me to the propper place in the code to fix it. >> >> See the attached patch >> >> Dave > > -- > Michael Kirkham > President & CEO > Muonics, Inc. > http://www.muonics.com/ > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ 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
