[snmp] SNMP Set Response is lost / packet dropped by Westhawk API

Kevin Bond hibond000 at gmail.com
Thu Jun 5 01:39:25 BST 2008


Hi Birgit,

    Thanks for your quick response and I apologize for my delayed reply.

    I resolved the issue after making some changes to the frequency of SNMP
V2C Context creation. I have given root cause observed to help you get a
better handle on the issue.

    In the project, I had an SNMP Adapter layer where I used to create a
Context to execute the command and destroy the context immediately after the
execution. This layer had no visibility on the frequency of execution.

    In the particular scenario, the layer using the SNMP Adapter sent a lot
of set requests in sequence (one by one). In this scenario WestHawk stack
had the mentioned problem in receiving the response from the device. I
changed the context handling to use the same SNMP V2c Context for subsequent
requests to avoid the problem.

   I am using the latest 6.0 stack and only V2C Contexts.

Hope this helps,
Kevin



On Thu, Jun 5, 2008 at 12:05 AM, Josh Bers <jbers at bbn.com> wrote:

> Birgit,
>
> In trying to understand why the stack might drop some responses, there are
> a
> few questions:
>
> 1. Are set requests retried the same way as get requests? Namely if a
> response is not received they are resent? (this might be risky for setting
> things that should only be set once...)
>
> 2. If an observer for receiving PDU responses does a lot of processing,
> what
> happens to the receiver thread that is listening on the inbound socket?
>
> If answer to above is that the receiver thread and the thread that calls
> update on the observer are the same then there may be a problem of dropping
> UDP packets...
> Since there are no guarantees on UDP and there is a finite queue that the
> OS
> has for UDP sockets (I think 5 deep is the default), then the TCP/IP in the
> OS may well just drop response PDU's when there are a lot of them and the
> Observers are causing calls to receivePacket to be spaced out.
>
> 3. If the answer to the above is that there is a separate thread to listen
> for response on the socket and a separate one that dispatches to observers,
> then there may be a queuing problem. How does the stack queue up these
> received packets?
>
> 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, June 03, 2008 2:44 AM
> To: List for discussion of the Westhawk SNMP stack
> Subject: Re: [snmp] SNMP Set Response is lost / packet dropped by Westhawk
> API
>
> Hi,
>
> This is not good news, it shouldn't happen.
> I currently don't have much time to investigate, sorry, and problems
> like this are not easy to reproduce.
>
> Which version of the stack are you using
> and which SNMP version are you using?
>
> Some background:
> As soon as a SnmpContext sends a request, it's run() method will keep
> listening for incoming responses until destroy() is called. Dealing with
> the response is done on the receive thread.
>
> It might be possible that the context misses an incoming request,
> however, the context retransmits the request a couple of times.
> There could be a race condition.
>
>
> Kevin,
> The AsnObject class has a static method called setDebug.
> If you call
>   AsnObject.setDebug(11);
> early on when using the stack, it will print out (amongst many other
> things) every message the SnmpContext receives.
>
> It won't fix your problem, but it will tell you if the stack receives
> the response at the lower level, but somehow not deals with it higher up.
>
> Could you look into it and let us know your findings?
>
> Thanks, Birgit
>
>
>
> On 30/05/08 22:07, Josh Bers wrote:
> > I too have noticed problems with set requests on the stack when
> attempting
> > to change snmpv3 passwords using the USM mib, RFC 3414...
> >
> > -----Original Message-----
> > From: snmp-bounces at snmp.westhawk.co.uk
> > [mailto:snmp-bounces at snmp.westhawk.co.uk] On Behalf Of Kevin Bond
> > Sent: Friday, May 30, 2008 5:37 AM
> > To: snmp at snmp.westhawk.co.uk
> > Subject: [snmp] SNMP Set Response is lost / packet dropped by Westhawk
> API
> >
> >
> > Hi,
> >
> >      I have been using WestHawk SNMP API for few years now.     Currently
> I
> > am facing a peculiar packet loss issue.
> >
> >      I have a program that sends a series of set requests to an SNMP
> > device. All the set-requests work perfectly in standalone. When executed
> one
> > after another, they execute successfully 5 out of six times in the other
> > instance I get a Timeout exception in a Random place.
> >
> > When I attempted to trace the packets with Wireshark (assuming that it is
> a
> > device problem) I noticed that the response for the set request was
> properly
> > received by the machine immediately, but It was not captured by the
> > particular Westhawk session.
> >
> > I am not sure how to fine tune the WestHawk API to prevent it from
> dropping
> > any packets. Thanks, Kevin
>  >
>
> --
> -- 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
>
>
> _______________________________________________
> snmp mailing list
> snmp at snmp.westhawk.co.uk
> http://snmp.westhawk.co.uk/mailman/listinfo/snmp
>


More information about the snmp mailing list