From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202508 header.b=V8fBTX4C; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 55A805A0276 for ; Thu, 02 Oct 2025 04:53:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202508; t=1759373583; bh=O+BwwqOxON2yw60htqhnuoPkAk+Y+rTHskZy6BcoeAk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V8fBTX4ChbgDFkMLANZCrFzihUcR3lm7TLkPOEkdPNlBci6y8xcvHgWVg5SGt3nDm JRpsMBur0np0dSg6pgRu0E2dsm2KlZo7KA9XDUrJIgceE08qbzZCGHGwn41SfpB+Is pySk5OIPhJI26J9XZYewBZuIeLQ4mR+oPh8q8fK1ph7UBaWkfbi8V+iH4U+Cs9mlKS 44m/526Wu7hsbTUkGORdbyVDDx1h9NLg19Q+KGB0uFfPw7Q8657M6bEh14epbWBZHG h7JsJUUSv1Rs1/dlTHa7md2Bx43EieaWgQn1QExJZkmOpEQ3s52ZfOMQAhtCyWR0Ib Qdg1TAP82rvnw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4ccbvM2cgvz4wDL; Thu, 2 Oct 2025 12:53:03 +1000 (AEST) Date: Thu, 2 Oct 2025 12:52:31 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 3/4] tcp: Don't consider FIN flags with mismatching sequence Message-ID: References: <20251002000646.2136202-1-sbrivio@redhat.com> <20251002000646.2136202-4-sbrivio@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ej/Sjyc4eJHv7eyb" Content-Disposition: inline In-Reply-To: <20251002000646.2136202-4-sbrivio@redhat.com> Message-ID-Hash: PFS7VJ7FX4F4E4FH2IY2XOWX2UPKLPYE X-Message-ID-Hash: PFS7VJ7FX4F4E4FH2IY2XOWX2UPKLPYE X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Ej/Sjyc4eJHv7eyb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 02, 2025 at 02:06:45AM +0200, Stefano Brivio wrote: > If a guest or container sends us a FIN segment but its sequence number > doesn't match the highest sequence of data we *accepted* (not > necessarily the highest sequence we received), that is, > conn->seq_from_tap, plus any data we're accepting in the current > batch, we should discard the flag (not necessarily the segment), > because there's still data we need to receive (again) before the end > of the stream. >=20 > If we consider those FIN flags as such, we'll end up in the > situation described below. >=20 > Here, 192.168.10.102 is a HTTP server in a Podman container, and > 192.168.10.44 is a client fetching approximately 121 KB of data from > it: >=20 > 82 2.026811 192.168.10.102 =E2=86=92 192.168.10.44 54 TCP 55414 =E2= =86=92 44992 [FIN, ACK] Seq=3D121441 Ack=3D143 Win=3D65536 Len=3D0 >=20 > the server is done sending >=20 > 83 2.026898 192.168.10.44 =E2=86=92 192.168.10.102 54 TCP 44992 =E2= =86=92 55414 [ACK] Seq=3D143 Ack=3D114394 Win=3D216192 Len=3D0 >=20 > pasta (client) acknowledges a previous sequence, because of > a short sendmsg() >=20 > 84 2.027324 192.168.10.44 =E2=86=92 192.168.10.102 54 TCP 44992 =E2= =86=92 55414 [FIN, ACK] Seq=3D143 Ack=3D114394 Win=3D216192 Len=3D0 >=20 > pasta (client) sends FIN, ACK as the client has no more data to > send (a single GET request), while still acknowledging a previous > sequence, because the retransmission didn't happen yet >=20 > 85 2.027349 192.168.10.102 =E2=86=92 192.168.10.44 54 TCP 55414 =E2= =86=92 44992 [ACK] Seq=3D121442 Ack=3D144 Win=3D65536 Len=3D0 >=20 > the server acknowledges the FIN, ACK >=20 > 86 2.224125 192.168.10.102 =E2=86=92 192.168.10.44 4150 TCP [TCP Ret= ransmission] 55414 =E2=86=92 44992 [ACK] Seq=3D114394 Ack=3D144 Win=3D65536= Len=3D4096 [TCP segment of a reassembled PDU] >=20 > and finally a retransmission comes, but as we wrongly switched to > the CLOSE-WAIT state, >=20 > 87 2.224202 192.168.10.44 =E2=86=92 192.168.10.102 54 TCP 44992 =E2= =86=92 55414 [RST] Seq=3D144 Win=3D0 Len=3D0 >=20 > we consider frame #86 as an acknowledgement for the FIN segment we > sent, and close the connection, while we still had to re-receive > (and finally send) the missing data segment, instead. >=20 > Link: https://github.com/containers/podman/issues/27179 > Signed-off-by: Stefano Brivio > --- > tcp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/tcp.c b/tcp.c > index 3f7dc82..5a7a607 100644 > --- a/tcp.c > +++ b/tcp.c > @@ -1769,7 +1769,7 @@ static int tcp_data_from_tap(const struct ctx *c, s= truct tcp_tap_conn *conn, > } > } > =20 > - if (th->fin) > + if (th->fin && seq =3D=3D seq_from_tap) > fin =3D 1; Can a FIN segment also contain data? My quick googling suggests yes. If so, doesn't this logic need to go after we process the data processing, so that seq_from_tap points to the end of the packet's data, rather than the beginning? (And the handling of zero-length packets would also need revision to match). > =20 > if (!len) > --=20 > 2.43.0 >=20 --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --Ej/Sjyc4eJHv7eyb Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmjd6O4ACgkQzQJF27ox 2Gd5gA/9FDgwlqVxaTTW83cYTfqQPyz//Lfmj/VYkX6mwWZVjR21uiT7i/l0P6wh Dz9eJ4qVH38ezvVVpYooTDJCV3IOnYmPpTk1XIBBgdAHFeK/8fofSZ5KmluCkpTp 80Uj6D6WLvugvnPGfDgIx99uFc9ZII9D7CCGT723CmzsJLTt6TplxzvoEYTrskw8 cRpRwl7Gy8hgKaDdFfApUKSdG6jKDSSxeAIQQu0CAoa8ZyglUdiwzwESl8aKQXyy +eSuCnS49F3x/+r0X9k8D2unZ3Kx3P4l6U0I8gjUkPUKtpf+BO/z5XvL7xYLcdrT jebluD2ljNdmRlZXwxZQA2O9H2FTkmmIFX16bB4NTGzmER1V4FYyo6+Qjb9ZSRcC E/7u5ScWEg4wJ+6q4Wf8Kgup3NlZIDUvJz89Grl2/AWFDAHWmOXtAPaYjjwsOE+K /2PlKZ8G/5CHSz3ofA1XyL1va5MLg5aVqlvpFOhxo4e6Hh/apbHTqkvZTj2U289l KoUoUWMd5Rc+SjGgtvjBAkOVNKLl+6goZa175XM8+eTS6IAc2nR/67SGkduX0W+d W87Rl85X9tGTiS7JgfRQ/kUkBIu+F9oZphDDbOHj9hApCibqSm/+OB3poR5Z+xeD H5GbiBu/t2g87s6w6tegv/F4sHb7CIJ/S+erzNG2XHIE1Pz8Sqc= =QJZM -----END PGP SIGNATURE----- --Ej/Sjyc4eJHv7eyb--