It looks like TCP conntrack is incorrectly treating "LAST ACK" (ACK
from peer for last FIN) as the sequence number comparison does not
take into account that the last ACK sequence number will be one
greater than the previous sequence number.
Here's the code that seems to be the cause of it in tcp_in_window()
[nf_conntrack_proto_tcp.c]:
pr_debug("tcp_in_window: I=%i II=%i III=%i IV=%i\n",
before(seq, sender->td_maxend + 1),
after(end, sender->td_end - receiver->td_maxwin - 1),
before(sack, receiver->td_end + 1),
after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1));
if (before(seq, sender->td_maxend + 1) &&
after(end, sender->td_end - receiver->td_maxwin - 1) &&
before(sack, receiver->td_end + 1) &&
after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1)) {
III in pr_debug will be 0 as "before(sack, receiver->td_end + 1)" will
evaluate to false as sack will be equal to (receiver->td_end + 1) for
the last ACK. The sequence number will be one greater in the last ACK.
Any feedback will be helpful. Thanks for looking into this.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
