aboutgitcodebugslistschat
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2025-10-02 01:13:27 +0200
committerStefano Brivio <sbrivio@redhat.com>2025-10-07 22:22:34 +0200
commit8efa80b51f9f52082954aa26719b36a9ec367567 (patch)
treeeb3d8b6406141c222c4c211ecec30393f8d6a8c6
parentb3217aa5aec10704774c7142ef07daec5e698415 (diff)
downloadpasst-8efa80b51f9f52082954aa26719b36a9ec367567.tar
passt-8efa80b51f9f52082954aa26719b36a9ec367567.tar.gz
passt-8efa80b51f9f52082954aa26719b36a9ec367567.tar.bz2
passt-8efa80b51f9f52082954aa26719b36a9ec367567.tar.lz
passt-8efa80b51f9f52082954aa26719b36a9ec367567.tar.xz
passt-8efa80b51f9f52082954aa26719b36a9ec367567.tar.zst
passt-8efa80b51f9f52082954aa26719b36a9ec367567.zip
tcp: Completely ignore data segment in CLOSE-WAIT state, log a message
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 <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
-rw-r--r--tcp.c8
1 files changed, 7 insertions, 1 deletions
diff --git a/tcp.c b/tcp.c
index 7da4179..a648174 100644
--- a/tcp.c
+++ b/tcp.c
@@ -2135,9 +2135,15 @@ int tcp_tap_handler(const struct ctx *c, uint8_t pif, sa_family_t af,
/* Established connections not accepting data from tap */
if (conn->events & TAP_FIN_RCVD) {
+ size_t dlen;
bool retr;
- retr = th->ack && !tcp_packet_data_len(th, l4len) && !th->fin &&
+ if ((dlen = tcp_packet_data_len(th, l4len))) {
+ flow_dbg(conn, "data segment in CLOSE-WAIT (%zu B)",
+ dlen);
+ }
+
+ retr = th->ack && !th->fin &&
ntohl(th->ack_seq) == conn->seq_ack_from_tap &&
ntohs(th->window) == conn->wnd_from_tap;