Hello!
> > OK, if you cannot regenerate the sequence of events (I know, it is not
> > so easy), I still can assume that you did a misprint there. Edit that
> > sample, at least.
>
> No. The third packet in the sequence does NOT reach host2 before the
> fourth packet is transmitted by host2. I don't see how that's invalid TCP
> behavior.
OK, if you are still in doubts, let me to analyze this.
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.
So, I conclude, that third line is wrong. It could look like:
* host1 --> host2 XSEQ+1:XSEQ+1(0) ack YSEQ+1
or it is retransmit of FIN:
* host1 --> host2 FIN XSEQ:XSEQ(0) ack YSEQ+1
In the first case, the further is straightforward. In the second case,
it is usual retransmit lockup case, common on bi-directional TCP
connections. It has nothing to do with FINs and nicelt resolved
in protocol with sending ACKs to all out-of-window segments.
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.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
