[snmp] Problem with the snmpv3 context

Tim Panton thp at westhawk.co.uk
Mon Mar 26 10:36:47 BST 2007


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 desireable).
>
> 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.





More information about the snmp mailing list