>This bug was fixed in the 2.0.3x series about a year ago. The approach
I think you are taking about another thing.
>there didn't have any adverse side effects -- since the bug only
>happens when the FIN/Data segment arrives out of order, and the
>data will get ack'ed by Solaris, the approach was (on the retransmit
>from the linux end) to *not* retransmit the ack'ed data. This leaves
The problem is not that we aren't retransmitting, the problem is that
Solaris doesn't look at the FIN flag and it thinks that the last octect of
data is present in the packet while it's only the FIN side effect.
> * Is the && test needed here? If so, then it implies that
> * we might be retransmitting an acked packet. This code is
> * needed here to talk to Solaris 2.6 stack.
We are just doing that in 2.2.2: Linux continue to retransmit the last
full-of-data packet with the FIN set. But Solaris instead of look at the
FIN flag least these _second_ times, drop it directly and send back to
Linux the latest ack because the sequence number of our packet with the
FIN set is not in its receive window (or better I am guessing this is the
reason: I don't have access at Solaris TCP stack sources ;).
Tell me if I misunderstood your point of course.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/