Messages in this thread | | | Date | Fri, 26 Feb 1999 13:30:38 -0500 | From | Philip Gladstone <> | Subject | Re: [patch] workaround for solaris 2.5.1 and 2.6 FIN bug (ID 4083814) |
| |
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[unhandled content-type:application/x-pkcs7-signature]
| |