TCP reset caused by socket.py

[Jeff McNeil]

Do you have any non-standard network hardware along the route?  Perhaps a
transparent proxy like a load balancer or a firewall of sorts? I've seen
this type of thing happen before with load balancer gear.   In my situation,
I had a load balancer that kept a state table. If the load balancer didn't
see client-side traffic within a 5 second period, it would terminate the
connection by sending some out of sequence data that generated the RST.
We spent half a day tracking down (what we thought was) a bug in one of our
Apache modules and it turned out to simply be a configurable timeout value.




On 12/12/07, Object01 <object01 at gmail.com> wrote:
>
> On Dec 12, 12:45 pm, Bjoern Schliessmann <usenet-
> mail-0306.20.chr0n... at spamgourmet.com> wrote:
> > Object01 wrote:
> > > The server is multithreaded, handling each request on its own
> > > thread.
> >
> > Ugh.
> >
> > > But is a RST really a part of a valid close operation?
> >
> > Depends on the state of the parties :) The proper way to close
> > non-defunct connections is using FIN segments.
> >
> > > It was my understanding that the RST is used to indicate a problem
> > > with the connection, usually a half-open connection.  I never see
> > > RSTs unless this error occurs.
> >
> > RFC793:
> >
> > | Reset Generation
> > |
> > | As a general rule, reset (RST) must be sent whenever a segment
> > | arrives which apparently is not intended for the current
> > | connection.  A reset must not be sent if it is not clear that this
> > | is the case.
> >
> > Regards,
> >
> > Björn
> >
> > --
> > BOFH excuse #347:
> >
> > The rubber band broke
>
> Is there something I can look for in the packet traffic that would
> indicate one party is misbehaving?  The sequence numbers seem ok.
> *shrug*  I'd expect to see data sent from server to client and then
> see a sequence of packets that close the connection gracefully.
> Instead I see the server send data to the client and then a RST,
> nothing more.
>
> The crux of this strangeness seems to be Python sending a RST without
> any prompting from the client.   It's just send to client, send to
> client, send to client, reset.  OH!  Maybe the client isn't
> acknowledging properly or the server is incorrectly expecting
> acknowledgment and resets when it doesn't arrive?
>
> Rrr...
>
> --
> Jeff S.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20071212/beac67ee/attachment.html>