httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <>
Subject Re: Win32 network glitch
Date Mon, 12 Jan 1998 09:49:16 GMT
On Sun, 11 Jan 1998, Marc Slemko wrote:
> On Sun, 11 Jan 1998, Paul Sutton wrote:
> > 16:17:27.290000 beavis.localnet.8001 > ecstasy.localnet.1819: . ack 13 win 8749
> > (DF)
> This looks like there is a connection in TIME_WAIT on the server so it
> sends an ACK on the old connection since the SYN isn't in the window.

Um, I should have used netstat on NT I guess to see how many TIME_WAITs
there were.

> > 1819 on the Linux client rather than 1814. This is obviously out of
> > sequence on port 1819 since no data has been sent, so Linux sends a reset
> > for this connection, and tries again three seconds later. The time the
> > connection works -- NT acknowledges with a SYN package.
> > 
> > Is this a correct interpretation? If so, does it mean that this is an NT
> > winsock bug because it is sending an ack to the wrong port after the
> > closedown of a previous connection? But if that was the case surely every
> > network service would have hit this problem and it would be widely known? 
> No, the two connections are unrelated.  You are being tricked by tcpdump's
> relative sequence numbers.  Use -S to see the real story.
> Take a longer term tcpdump and see when the _previous_ connection from the
> client to the server on that port was.  I would bet it is <2*MSL so you
> still have it hanging around in TIME_WAIT.
> Nothing that you would normally see unless one client is making a lot of
> requests to one server.

Oh, ok. Thanks for the analysis. So it is not something to get
particularly upset about, then? But is does make stress testing more
difficult -- is there any way to force Linux to use a larger range of
ports for the connection requests? Are other operating systems better for


View raw message