Re: connect() bug?

Alan Cox (
Sun, 14 Sep 1997 13:56:55 +0100 (BST)

> Oh, hell yes it is... I've been watching several Linux machines exhibit
> connects that don't connect and never timeout for weeks now. The Bovine
> rc5 client seems to be very likely to step into it...

Do you have a nice reproducable case under 2.0.31pre* ?

> Sep 13 10:55:33 idemo1 kernel: tcp_input.c: tcp_rcv_state_process(): [0039B841]
> -> Syn: Ack+Rst [discard]

So someone sent an RST frame with wrong sequence space.

> It doesn't always happen like that, and it doesn't _have to_ happen like that
> either. The remote side can simply Ack the Linux Syn packet and the connection
> is then half open, then send it's own Syn. Linux does not handle that. And
> as I read the comments/source, the kernel thinks that's never going to happen.

I don't believe so. In that situation the sequence space from the remote end is
unknown. Until we get a SYN|ACK reply to the SYN we cannot send an ACK and
nor can they as the frame isnt valid. I can believe there might be a case
where a timer gets cleared wrongly. But ACK without SYN to a SYN doesn't
move your state.

> [And for those looking at that and wondering about the timeout times, yes, I
> changed the progression, and I'm likely to make it even more agressive.]

The timeout times are laid down in RFC1122. They are chosen with specific
requirements and mathematical constraints to control congestion.