> I'm performing a benchmark test to a local linux website. When
> I monitor packet sequences at the website with tcpdump, I found
> that when tcp socket is in TIME_WAIT state, the default response to a
> retransmitted FIN packets is to silently drop them. Is this the correct
> way of implementing TIME_WAIT? The website was runing on
> 2.2.19 kernel, and when I change it to 2.4.9, tcp becomes more
> active and start sending back FIN-ACKs.
>
> I saw different explainations on the purpose of TIME_WAIT state,
> some of them (including Stevens' book) say that it can deal with
> losses of the last FIN or FIN-ACK packet in addition to
> preventing reuse of same address-port pair immediately.
>
> I also glimpsed through TCP implementations in both kernels.
> Although both claim to be conformant to RFC 1122, the code
> themselves are quite different. And I couldn't find
> anywhere in the 2.2.19 kernel implementation that tells
> TCP to respond to duplicate FINs except in tcp_timewait_state_process:
>
> /* Ack old packets if necessary */
> if (!after(TCP_SKB_CB(skb)->end_seq, tw->rcv_nxt) &&
> (len > (th->doff * 4) || th->fin))
> return TCP_TW_ACK;
> return 0;
>
> Which I suspect contains some bug.
> I've searched the archive and found a related message was posted
> almost 3 years ago:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=93293686728605&w=2
> Seems that the "|| th->fin" condition was the ad-hoc patch for
> the problem. And if it is, shouldn't the "&&" be "||" in the
> if condition?
>
> Again, my question is whether 2.2.19 is doing correct things,
> and if not, can I replace tcp implementation in 2.2.19 by
> that in 2.4.9 and how? Or some alternative milder changes?
>
> Thank you very much.
>
>
> Guo, Liang
>
> [email protected] Dept. of Comp. Sci., Boston Univ.,
> (617)353-5222 (O) 111 Cummington St., MCS-217,
> (617)375-9206 (H) Boston, MA 02215
>
>
Hello!
> > that when tcp socket is in TIME_WAIT state, the default response to a
> > retransmitted FIN packets is to silently drop them. Is this the correct
> > way of implementing TIME_WAIT?
No. Linux 2.2 is not expected to have this bug.
> > active and start sending back FIN-ACKs.
No. time-wait never send FINs, just bare ACK.
> > /* Ack old packets if necessary */
> > if (!after(TCP_SKB_CB(skb)->end_seq, tw->rcv_nxt) &&
> > (len > (th->doff * 4) || th->fin))
> > return TCP_TW_ACK;
> > return 0;
> >
> > Which I suspect contains some bug.
It should responce right. end_seq == rcv_nxt in the case of retransmitted
FIN, len == th->doff*4 but th->fin == 1. So, it returns TCP_TW_ACK.
So, it looks right, I have no idea what happens in your case.
Apparently, you diagnosed problem wrongly. It would be better
if you sent tcpdump of bad session instead.
> > Again, my question is whether 2.2.19 is doing correct things,
Supposed to do. If it does not, alas.
> > that in 2.4.9 and how? Or some alternative milder changes?
Milder change is just to install 2.4. :-)
Alexey