[CLUE-Tech] Linux TCP sockets SYN -> long delay waiting for tcp_syn_retries

[David Anselmi]

Jim Ockers wrote:
[...]
> The connection is to a closed port, so I think there is no sequence
> number.  The SYN sent packets seemed to have a seq of 0, and the I
> didn't observe a seq on the RST packets that came back.

Yes, there is.  Ethereal shows you what they call a relative sequence 
number, which is 0 for the SYN packet.  But if you look at the data 
you'll see what it really is (this is the initial sequence number and 
has to be random to inhibit spoofing attacks).

> The TCP checksums were all good in every packet I looked at.

This suggests either the server is sending incorrectly (no ACK) or the 
transmission path is rewriting the header (removing the ACK and 
recalculating the checksum).

[...]
>>From RFC793:
> 
>   Reset Processing
> 
>   In all states except SYN-SENT, all reset (RST) segments are validated
>   by checking their SEQ-fields.  A reset is valid if its sequence number
>   is in the window.  In the SYN-SENT state (a RST received in response
>   to an initial SYN), the RST is acceptable if the ACK field
>   acknowledges the SYN.
> 
> So I think I'm correct in saying that there is no sequence number for
> RST-ACKs but if it is RST then ACK must be set as well.  Interestingly
> it appears that Windows 2000 accepts the RST even if the ACK bit is
> not set.

Any time the ACK is set the acknowledgement field will contain a 
number--in this case the ISN +1.  That's what "if the ACK field 
acknowledges the SYN" means.  Again, you can see it in the data if 
ethereal shows a relative sequence number.

Be interesting to hear what the cause of this is, in the end.

Dave