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]
> 199.72.252.1:1172 -> 207.88.23.246:2056 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.
Alan