Andrea Arcangeli wrote:
> >This bug was fixed in the 2.0.3x series about a year ago. The approach
>
> I think you are taking about another thing.
I think that is *is* the same problem.
>
> >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.
I think that you misunderstood me. The problem (as I diagnosed it) was
that Solaris sometimes ignores the FIN flag in TCP packets with data.
However, it processes the data. [As I recall it would ignore the FIN
on a packet received when there was a gap in the receive sequence space.
Then when the retransmitted packet arrived, it was being dropped as
a duplicate.]
The fix was to make sure that we did *not* retransmit the data, but
*do* retransmit the FIN. When Solaris receives the FIN without data
it handles it correctly.
>
> > * 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.
The point is *not* to retransmit the last full packet, but just
retransmit
the FIN. [This is more economic on sending data anyway]
Philip
--
Philip Gladstone +1 781 530 2461
Axent Technologies, Waltham, MA
S/MIME Cryptographic Signature
