On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
> Third line cannot follow the first one, because the first means
> that SND.NXT is advanced. It is not linux, it is a buggy stack.
> But you tried to cure the problem on host1, hence I have to assume,
> that host1 is linux. Contradiction. Line 3 is wrong, QED.
Okay. Got that.
> By the way, leaving dry logic, reality introduces some corrections. 8)
> If one of hosts is linux 2.1 or early 2.2, one side will finish in temporary
> lockup due to time-wait bug. If one side is not 2.3 or the latest 2.2,
> the connection will be reset due to another bug, fixed very recently.
It _was_ early 2.2... the behavior observed was of a large number of
connections remaining in CLOSING state. Apparently the ACK of the FIN that
host2 sent (host1 was my box) was dropped because host2 also set the FIN
flag on it, even though that FIN was already ACKed. Effectively, host2 was
sending TWO FINs in the stream -- non-RFC behavior for sure.
The comment in the source must have a typo, yes. Since host1 is linux, it
must be sending XSEQ+1:XSEQ+1 ACK YSEQ+1 in the third line. However, the
tcp_sequence check will still drop the fourth packet if end_seq ==
rcv_nxt, no?
Taral
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
