Re: TCP LAST-ACK state broken in 2.4.17-pre2

From: Pasi Sarolahti (sarolaht@cs.Helsinki.FI)
Date: Thu Dec 13 2001 - 05:19:56 EST

Hash: SHA1


Mika wrote:
> Looks like there are still problems after applying your quick patch.
> Back at the lab we observed a case where the FIN-ACK packet is dropped
> and Linux fails to retransmit it. See the attached dump for the details
> (Linux is The action ends there, with Linux timing out to
> CLOSED state and the remote stuck in FIN-WAIT-2.

I think following might happen: When the receiver gets FIN and acks it, it
should be in CLOSE_WAIT or LAST_ACK state depending on the situation,
right? In tcp_rcv_state_process() the receiver calls ack_snd_check, which
has the following test:

            if (!tcp_ack_scheduled(tp)) {
                /* We sent a data segment already. */
        __tcp_ack_snd_check(sk, 1);

I think in this situation it may be possible that ack_scheduled is false,
which would mean that the receiver never acks the further FIN segments if
the first FIN-ack is lost. Maybe something like the following might work,
although it looks pretty ugly :-)

       if (!tcp_ack_scheduled(tp) &&
                                      (sk->state == TCP_ESTABLISHED ||
                                       sk->state == TCP_FIN_WAIT1)) {
                /* We sent a data segment already. */

(Btw, I'm not on the lkml, so I would like to be cc'd of the further
discussion on this thread)

- - Pasi

- --
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:25 EST