According to RFC 9293 we should ignore data (note: not data segments)
in CLOSE-WAIT state (indicated by TAP_FIN_RCVD), see 3.10.7.4
"Other states":
[...]
Seventh, process the segment text:
[...]
CLOSE-WAIT STATE
This should not occur since a FIN has been received from the remote
side. Ignore the segment text.
and we almost do that, except that we would look at the data length
to decide whether it's a request for fast re-transmission, so fix
that, and while at it, log a message, so that cases such as the
following one are more apparent in debug logs:
28692 0.009758 88.198.0.164 → 93.235.151.95 54 TCP 55414 → 47080 [FIN, ACK] Seq=121441 Ack=141 Win=65536 Len=0
we should ignore this FIN flag, because we didn't accept data up
to this sequence (see next segment), but we don't do it, so, here:
28693 0.000036 93.235.151.95 → 88.198.0.164 54 TCP 47080 → 55414 [ACK] Seq=141 Ack=90722 Win=32128 Len=0
28694 0.034597 93.235.151.95 → 88.198.0.164 54 TCP 47080 → 55414 [FIN, ACK] Seq=141 Ack=90722 Win=121216 Len=0
28695 0.000019 88.198.0.164 → 93.235.151.95 54 TCP 55414 → 47080 [ACK] Seq=121442 Ack=142 Win=65536 Len=0
28696 0.162968 88.198.0.164 → 93.235.151.95 30773 TCP [TCP Retransmission] 55414 → 47080 [FIN, PSH, ACK] Seq=90722 Ack=142 Win=65536 Len=30719 [TCP segment of a reassembled PDU]
we are erroneously in CLOSE-WAIT (TAP_FIN_RCVD) state, and this
segment would look pretty strange there.
This specific case is fixed by the next patch, so it should never
happen again.
Link: https://archives.passt.top/passt-dev/20250910115726.432bbb8d@elisabeth/
Link: https://bugs.passt.top/show_bug.cgi?id=126
Suggested-by: David Gibson