Re: Problem with TCP connection not opening properly

From: Tony Mountifield (tony_at_softins.clara.co.uk)
Date: 04/02/04 

Date: 2 Apr 2004 20:51:07 +0100

In article <c4i7p7$bh$1@squay.lomarline.freeserve.co.uk>,
pbs <pnews@lomarline.freeserve.co.uk> wrote:
> Alex Butcher wrote:
> >
> > Looks like either a faulty stateful firewall somewhere in between the
> > hosts, or blackholing due to packet size, or a bug (probably) in the 2.2
>
> That packets get lost occasionally is not realy realy an issue here. It
> may be happening too often for comfort and it may be some intermediary
> that is causing it. But fixing any intermediary will only mask the real
> question.
>
> The real question is should the client send an ACK when the server
> re-sends the SYN-ACK because the server has not received the client's
> final ACK in the 3 way hand-shake?

Yes, this is exactly my point. My 2.2.19 client seems not to send
another ACK, which results in the connection hanging. Also, I suspect
that my colleague's Windows client may be doing the same thing.

> I have always found the State diagram on page 23 of RFC793
> TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM ... helpful when
> discussing issues like this.
> http://www.faqs.org/rfcs/rfc793.html
>
> After sending the ACK the client has moved from the SYN SENT state
> into the ESTAB state. It can now accept data and a FIN but should
> it still accept a SYN packets?
>
> Like Tony Mountifield I've been looking around for an answer, in my case
> on the net and I can not find any examples of how a loss of an ACK at
> the end of the 3 way HS should be handled.

Yes, even Stevens vol 1 doesn't cover this. I've just looked through
vol 2 in the TCP Input chapters, and couldn't see a mention there either.

> But I have come across two comments which do relate to this.
>
> 1) If either party does not leave the SYN/RCVD/SENT state but continues
> to send SYN.ACK packets could that be a denial of service attack?

I would say only if the server wilfully continues to send SYN.ACKs despite
having received and understood the client's initial ACK. The client should
respond to at least several duplicate SYN.ACKs before giving up.

> 2) If the client does not move from the SYN/SENT state to the ESTAB
> state then it would not be legitimate for it to handle FIN packets.

The client has to move to the ESTAB state after sending its initial ACK.
It just should be prepared to ACK duplicate SYN.ACKs while in that state.

Since I am suspicious that more than one client may be faulty in this
regard, I would be very interested to modify a kernel such that when a
socket is in SYN_RCVD state, it ignores the first client ACK it receives
but correctly processes subsequent ones. Putting a server on such a system
and then running test clients against it from various OSes might be very
revealing, to see how they handle this forced situation. If only I had the
time.....

Thanks for your input.

Cheers,
Tony 

-- 
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org
Loading