Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync

[Manfred Spraul]

> Yes, Linux is __very__ not right doing this. RFC requires to accept
> ACK, URG and RST on any segment adjacent to window, even if window
> is zero.
> 
Interesting: I checked the RFC 793 and came to the conclusion that Linux
is correct. ("special allowance should be made to accept valid ACKs" not
must be). Is there another RFC?

Note that either segment length is > 0 or SEG.SEQ != RCV.NXT

But I spotted a second problem, might be minor:

Could you check what happened in line 2066 of this tcpdump?

in line 2064 static (2.2.18-pre17) ack'ed 1583721.
in line 2066 dynamic (Solaris 7.0) sends data although the window is 0
in line 2067 static complains, but now ack is 1583720

2060  16:31:42.879337 eth0 < dynamic.ih.lucent.com.39406 > static.8664:
. 67580:67580(0) ack 1582261 win 1460 (DF)
2061  16:31:42.907940 eth0 > static.8664 > dynamic.ih.lucent.com.39406:
. 1583721:1583721(0) ack 67580 win 1460 (DF)
2062  16:31:42.908620 eth0 < dynamic.ih.lucent.com.39406 > static.8664:
. 67580:67581(1) ack 1583721 win 0 (DF)
2063  16:31:43.098761 eth0 > static.8664 > dynamic.ih.lucent.com.39406:
. 1583721:1583721(0) ack 67581 win 1460 (DF)
2064  16:31:43.100993 eth0 < dynamic.ih.lucent.com.39406 > static.8664:
P 67581:68456(875) ack 1583721 win 0 (DF)
2065  16:31:43.101524 eth0 < dynamic.ih.lucent.com.39406 > static.8664:
P 68456:69041(585) ack 1583721 win 0 (DF)
2066  16:31:43.108759 eth0 > static.8664 > dynamic.ih.lucent.com.39406:
. 1583720:1583720(0) ack 69041 win 0 (DF)
2067  16:31:43.110623 eth0 < dynamic.ih.lucent.com.39406 > static.8664:
P 69041:69628(587) ack 1583721 win 0 (DF)
2068  16:31:43.110679 eth0 > static.8664 > dynamic.ih.lucent.com.39406:
. 1583721:1583721(0) ack 69041 win 0 (DF)

An off-by-one error somewhere in tcp_send_ack()?
A second packet with the off-by-one ack number is send a few packets
later, all other packets are correct.
--
	Manfred