[snmp] Problem with the snmpv3 context

[Josh Bers]

Birgit and Tim,

Here is the output from the stack when debug set at level 15.

The scenario here is slightly different than I described before:
 Here we do the test on the loopback interface (since it's easier to test
than with two machines and produces the same results)

Look for 
"Bringing down the loopback interface"

Then it starts to query for sysName among other OID's about 2 minutes later
it
Brings the loopback interface up

Then the stack stops receiving data.

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: Monday, March 26, 2007 5:34 AM
> To: List for discussion of the Westhawk SNMP stack
> Subject: Re: [snmp] Problem with the snmpv3 context
> 
> 
> On Mon, Mar 26, 2007 at 09:36:47AM +0100, Tim Panton wrote:
> > 
> > On 23 Mar 2007, at 21:16, Josh Bers wrote:
> > 
> > >I am seeing a problem while using version 5.1 of the stack (running
> > >on
> > >linux, java 1.4.2_12) talking to an SNMP agent with 
> version 3 with  
> > >privacy
> > >and authentication turned on.
> > >
> > >The scenario is the following:
> > >
> > >The program repeatedly attempts to contact an agent that is
> > >unreachable
> > >(network cable unplugged). After a long period of time (>3 
> minutes)  
> > >the
> > >network cable is plugged back in.
> > >
> > >The stack behavior is:
> > >
> > >While disconnected, we see messages about USMDiscovery Bean timing
> > >out
> > >trying to connect to the agent. The stack dump show 2 receivers  
> > >associated
> > >with the disconnected target IP address (?) These timeouts are  
> > >repeated for
> > >each attempt (timeouts take ~20 seconds). When the cable is  
> > >reconnected, the
> > >2 receiver threads suddenly die. No more USMDiscoveryBean 
> timeouts  
> > >are seen,
> > >however, no every PDU that is sent times out waiting for a 
> response  
> > >(makes
> > >sense given that the receiver has died).
> > >
> > >Anyone else seen this? Know why? Any workaround? Swapping 
> to Version
> > >1
> > >context solves the problem (but this is not desirable).
> > >
> > >Theory:
> > >USMDiscovery Creates its own v3 context (not sure why it can't
> > >reuse the one
> > >created for the original PDU??) Somehow when it kills this 
> context  
> > >it kills
> > >the context (or at least the receiver thread) of the PDU's 
> context...
> > >(notify issue?)...
> > 
> > Ah, Interesting.
> > 
> > Do you have an ethereal trace of the packets - including ICMP ? 
> > Combined with a debug log we should be able to find the problem
> > pretty fast.
> > (other pressures permitting :-) )
> > 
> > I dimly remember hearing that different UDP implementations throw
> > different
> > exceptions when an intermediate router sends an 
> 'unreachable' or the  
> > local
> > system reports 'no-route-to-host'. I'll ask the folks who reported  
> > the problem what
> > they did.
> > 
> > Tim.
> 
> 
> Hi Josh,
> 
> To add to Tim's reply ..
> 
> See if you get anything useful when setting the debug level 
> quite high 
> ( AsnObject.setDebug(13); )
> 
> As to why the v3 context cannot use the original PDU:
> EngineId (and then Timeline) discovery requires different 
> context parameters.
> 
> Cheers, Birgit
> 
> -- 
> -- Birgit Arkesteijn, birgit at westhawk.co.uk,
> -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK
> -- Company no: 1769350
> -- Registered Office: 
> -- 15 London Road, Stockton Heath, Warrington WA4 6SJ. 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
>