[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