Re: FOLLOWUP: Small problem with TCP socket opening
Matthias Urlichs (smurf@lap.noris.de)
26 Aug 1997 15:13:29 +0200
Ricky Beam <root@defiant.interpath.net> writes:
>
> Connection Hung:
> 14:26:50.558372 199.72.252.1.2320 > 128.101.162.50.2056:
> S 2424233590:2424233590(0) win 32767 <mss 1460> (DF)
> 14:26:53.558372 199.72.252.1.2320 > 128.101.162.50.2056:
> S 2424233590:2424233590(0) win 64240 <mss 1460> (DF)
> 14:26:58.558372 199.72.252.1.2320 > 128.101.162.50.2056:
> S 2424233590:2424233590(0) win 64240 <mss 1460> (DF)
> 14:26:58.728372 128.101.162.50.2056 > 199.72.252.1.2320:
> . ack 2424233591 win 8760 (DF)
> 14:26:58.728372 199.72.252.1.2320 > 128.101.162.50.2056:
> R 2424233591:2424233591(0) win 0
>
> This would indicate a larger problem... it would appear, the remote system
> got one of the SYNs but the SYN/ACK was lost. I get back a plain ACK, then
> attempt to reset the connection, but no timeout gets set anywhere to clear
> the stalemate. The process will never get any indication of trouble; it
> calls 'connect()' never to return.
>
I don't understand why should the connection be reset here in the first
place.
We sent a SYN, get an ACK back. The connection is now half-open. We're
still waiting for their SYN so that we can send our ACK back to them. After
that, the connection would be fully open.
The usual practice of sending SYN+ACK replies when we're passively opened
is only an optimization which can be skipped, eg. if both sides
simultaneously open a connection to the other (yes, TCP explicitly allows
this, read the RFC).
--
Matthias Urlichs