TCP reset caused by socket.py

[Object01]

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.