> Referring to the passage from RFC 793 I quoted earlier, (i.e. "The only
> thing that can arrive is a retransmission of the FIN") maybe this should
> only send an ACK if the FIN bit is set and (TCP_SKB_CB(skb)->end_seq ==
> tw->rcv_nxt)?
RFC suffers of too colorific language sometimes. 8)
Your mistake is evident: if peer in LAST-ACK or CLOSING has not-ACKed
data and our ACK was lost once, peer will never retransmit FIN,
retransmitting not-ACKed data. Hence all the segments must be ACKed.
Follow formal "SEGMENT ARRIVES" rules to understand correct sequence
of actions.
> tw->rcv_nxt)? Anything else is probably just an uninteresting old
> duplicate and should be silently dropped, I think. (be conservative in
> what you send, etc etc)
Specs are not ambigous in this place. In synchronized state all out-of-window
packets but RSTs shall be acked. There are no exceptions.
> Why assume that there was no data in the packet? Wouldn't
>
> rth.ack_seq = htonl(TCP_SKB_CB(skb)->end_seq);
>
> be better?
Formally, yes. But the combination in kernel works too.
Packets without ACK may be originated only if peer is in SYN-SENT
state and even if peer sends SYNs with data the RST will be valid
and accepted by peer for any ack==seq+syn...end_seq.
Probably, it will fail with T/TCP, but we do not make T/TCP in any case.
> (and besides, why would we be generating an ACK for a data-less and
> FIN-less packet?)
Because it is required by specs. See above and specs.
To be honest, I also do not see any places, where suppressing such ACKs
can break protocol, but it is not enough argument not to follow specs yet. 8)
Actually, ACKing ACKs is even dangerous. It may result in infinite
ACK loop in the case of desynchronized connection. However, we cannot suppress
them without full analysis of the protocol.
Alexey Kuznetsov
-
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/