[snmp] slow snmp v3 discovery timeout

[Josh Bers]

Birgit and Gejo,

Thanks for the response. A questions:

> > well in my case i was working with Westhawk Stack version 
> 4_13, i have 
> > switched off 
> > the authentication and privacy flags in the context. also while 
> > initialising the context 
> > call TimeWindow.setSnmpEngineId(host, port, engineId), this 
> will stop
> > the discovery of engineId every time before sending a packet

I am using 5_1 of the stack. I cannot turn off privacy or authentication (as
they are required by my application), however, I can provide the engineid.
In this configuration will it still attempt discovery before first
contacting the agent?

Josh

> -----Original Message-----
> From: snmp-bounces at snmp.westhawk.co.uk 
> [mailto:snmp-bounces at snmp.westhawk.co.uk] On Behalf Of Birgit 
> Arkesteijn
> Sent: Tuesday, January 30, 2007 5:58 AM
> To: List for discussion of the Westhawk SNMP stack
> Subject: Re: [snmp] slow snmp v3 discovery timeout
> 
> 
> On Tue, Jan 30, 2007 at 10:53:50AM +0530, 
> Gejo.Thayil at aricent.com wrote:
> > >In working with snmpv3 contexts, I've found that sending a Pdu 
> > >request to an
> > >agent is not there takes a long time to return ~19 seconds. When I
> > >looked
> > >into the code, it looks as though the v3 context is using a 
> > >UsmDiscoveryBean
> > >to discover the v3 engineid and other parameters if that agent has
> > >never been contacted.
> > 
> > 
> > well in my case i was working with Westhawk Stack version 
> 4_13, i have 
> > switched off 
> > the authentication and privacy flags in the context. also while 
> > initialising the context 
> > call TimeWindow.setSnmpEngineId(host, port, engineId), this 
> will stop
> > the discovery of engineId every time before sending a packet
> 
> 
> That would certainly help if you know what the engineId is.
> However, Gejo, I would like to point out that the stack doesn't do
> recovery "every time before sending a packet".
> It only does it if the engineId is unknown, i.e. the first 
> time and when
> discovery failed previously (Josh's problem).
> 
> 
> > >The bean class uses the default timeout when sending the Pdu
> > >request for discovery. However, I had set a different 
> retry_array on
> > >the
> > >original Pdu that is causing the discovery to be sent in the first
> > >place. 
> > >It
> > >would make sense for the stack to use this retry array when sending
> > >the
> > >discovery Pdu as well. Or at a minimum provide a way to change the 
> > >default
> > >retry array for v3 discovery. Perhaps there is another way 
> to do this 
> > >that
> > >won't take so long that I am missing.. suggestions welcome.
> >  
> > >Josh
> > 
> > 
> > why don't you add the same retry array before v3 Discovery, i.e in 
> > UsmDiscoveryBean.java 
> > when you are creating an instance of DiscoveryPdu, just call method 
> > pdu.setRetryInterval(retry_array)
> > and set the retries required there.
> 
> 
> I'm not sure that is possible. 
> pdu.setRetryInterval is not a static method:
> ( public void setRetryIntervals(int rinterval[]) )
> 
> and I don't see how you'd get your hands on the DiscoveryPdu object,
> created in UsmDiscoveryBean (that is created in SnmpContextv3Basis).
> 
> I agree with Josh, parameters such as the retry_interval should be
> copied from Pdu to DiscoveryPdu via UsmDiscoveryBean.
> That probably means new methods
> - Pdu.getRetryIntervals()
> - UsmDiscoveryBean.setRetryIntervals()
> 
> 
> > Regards
> > Gejo Joseph
> 
> 
> Cheers, Birgit
> 
> -- 
> -- Birgit Arkesteijn, birgit at westhawk.co.uk,
> -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK
> -- tel.: +44 (0)161 237 0660
> -- <URL: http://www.westhawk.co.uk>
> _______________________________________________
> snmp mailing list
> snmp at snmp.westhawk.co.uk
> http://snmp.westhawk.co.uk/mailman/listinfo/snmp
>