[snmp] Problem with the snmpv3 context

[Tim Panton]

I'm not sure either, it's just that the 'no route  to host' issue  
rang an alarm bell,
so I wanted to be sure that any packet trace contained the ICMPs too.

Tim.

On 26 Mar 2007, at 17:51, Josh Bers wrote:

> Tim and Birgit,
>
> I hope to get some debug output to send you soon on this issue.
>
> Tim, I'm not sure how it could be a UDP issue since the behavior  
> changes for
> SNMPv1 (it works fine).
>
> Josh
>
>> 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.
>>
>
>> -----Original Message-----
>> From: snmp-bounces at snmp.westhawk.co.uk
>> [mailto:snmp-bounces at snmp.westhawk.co.uk] On Behalf Of Tim Panton
>> Sent: Monday, March 26, 2007 4:37 AM
>> To: List for discussion of the Westhawk SNMP stack
>> Subject: Re: [snmp] Problem with the snmpv3 context
>>
>>
>>
>> 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.
>>
>>
>>
>> _______________________________________________
>> snmp mailing list
>> snmp at snmp.westhawk.co.uk
>> http://snmp.westhawk.co.uk/mailman/listinfo/snmp
>>
>
>
>
> _______________________________________________
> snmp mailing list
> snmp at snmp.westhawk.co.uk
> http://snmp.westhawk.co.uk/mailman/listinfo/snmp