Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote:
> > The ESTABLISHED timeout is 5 minutes because of missing ACKs
> > (outstanding data) in this case though (the RST has "wrong" sequence
> > number, so the conntrack is flagged accordingly until something acks the
> > data).
>
> Sorry, but I don't see where is the outstanding data. Up to the RST and
> the challenge ACK there's no missing ACK. The RST hasn't got wrong seq
> because it's in the window. The RST flag is not counted. What do I miss?
There is no outstanding data, but conntrack thinks there is.
If we have this:
seq 100 ack x len 100
seq 200 rst x len 0
Then rst is accepted immediately and we move to CLOSE.
When we get this:
seq 100 ack x len 100
seq 210 rst x len 0
Then from conntrack point of view, we're 10 bytes "short" because td_end
is 200, and new sequence is 210. So we hit this:
if (after(end, sender->td_end)) {
sender->td_end = end;
sender->flags |= IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED;
}
in tcp_in_window().
> If the conntrack timeout is not the ESTABLISHED one after the challenge
> ACK is seen, that's perfect.
The challenge ACK will use last in-sequence number as seen by the
receiver, so 200 in this case.
If it would be 210, then that would mean that conntrack, for some
reason, did not see those 10 bytes, but the real endpoint did.
And in that case we'd move back to full ESTABLISHED timeout.
