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=202410 header.b=kK/pEHrE; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id ECEB35A061B for ; Wed, 20 Nov 2024 02:02:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202410; t=1732064544; bh=D8ZF34wJyK8qJ8nF6g0GOaagvXnwbcLavz+8CXg3oxg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kK/pEHrEXUejifIP+TFEK0n30O/GzC2os4JG61+R9yxT2omYbVwwoLaBHVd5GmDBX g/IOd5yZTHYnHqCZpOGJcUvwaQMW7iBMzcDIfSgT8ny12NyJZxpHRPN8XkIEEtjjYu GR6TKmWZuXp30eg8jtiY0Cpx8cOmmeCmNN2URGZpoizGQbPDFpxDvmU1F/gc1zVXT1 yAtRYwKp+jEhQpIi7+EnPezVPrCKVsTmJO6KzNvfzUXlOpvYQHhkreCdXibkxMoAxj ddF1+rPzOE486QZoVV/+DgRAHtGNRCB4Xfs+FpgPnOrkKsOXBKgRYszMH9YXXE/n3+ PqeMFuE4hMG8g== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4XtNPX6d6Pz4xgh; Wed, 20 Nov 2024 12:02:24 +1100 (AEDT) Date: Wed, 20 Nov 2024 12:02:00 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 2/2] tcp: Acknowledge keep-alive segments, ignore them for the rest Message-ID: References: <20241119195344.3056010-1-sbrivio@redhat.com> <20241119195344.3056010-3-sbrivio@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JEG0QPm2//ZL56WB" Content-Disposition: inline In-Reply-To: <20241119195344.3056010-3-sbrivio@redhat.com> Message-ID-Hash: TUP3VLQMKVZTAZA26CHAPZ6ZDUKRT6BT X-Message-ID-Hash: TUP3VLQMKVZTAZA26CHAPZ6ZDUKRT6BT 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, Tim Besard 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: --JEG0QPm2//ZL56WB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 19, 2024 at 08:53:44PM +0100, Stefano Brivio wrote: > RFC 9293, 3.8.4 says: >=20 > Implementers MAY include "keep-alives" in their TCP implementations > (MAY-5), although this practice is not universally accepted. Some > TCP implementations, however, have included a keep-alive mechanism. > To confirm that an idle connection is still active, these > implementations send a probe segment designed to elicit a response > from the TCP peer. Such a segment generally contains SEG.SEQ =3D > SND.NXT-1 and may or may not contain one garbage octet of data. If > keep-alives are included, the application MUST be able to turn them > on or off for each TCP connection (MUST-24), and they MUST default to > off (MUST-25). >=20 > but currently, tcp_data_from_tap() is not aware of this and will > schedule a fast re-transmit on the second keep-alive (because it's > also a duplicate ACK), ignoring the fact that the sequence number was > rewinded to SND.NXT-1. >=20 > ACK these keep-alive segments, reset the activity timeout, and ignore > them for the rest. >=20 > At some point, we could think of implementing an approximation of > keep-alive segments on outbound sockets, for example by setting > TCP_KEEPIDLE to 1, and a large TCP_KEEPINTVL, so that we send a single > keep-alive segment at approximately the same time, and never reset the > connection. That's beyond the scope of this fix, though. >=20 > Reported-by: Tim Besard > Link: https://github.com/containers/podman/discussions/24572 > Signed-off-by: Stefano Brivio > --- > tcp.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) >=20 > diff --git a/tcp.c b/tcp.c > index f357920..1eb85bb 100644 > --- a/tcp.c > +++ b/tcp.c > @@ -1763,6 +1763,20 @@ static int tcp_data_from_tap(const struct ctx *c, = struct tcp_tap_conn *conn, > continue; > =20 > seq =3D ntohl(th->seq); > + if (SEQ_LT(seq, conn->seq_from_tap) && len <=3D 1) { > + flow_trace(conn, > + "keep-alive sequence: %u, previous: %u", > + seq, conn->seq_from_tap); > + > + tcp_send_flag(c, conn, ACK); > + tcp_timer_ctl(c, conn); > + > + if (p->count =3D=3D 1) > + return 1; I'm not sure what this test is for. Shouldn't the continue be sufficient? > + > + continue; > + } > + > ack_seq =3D ntohl(th->ack_seq); > =20 > if (th->ack) { --=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 --JEG0QPm2//ZL56WB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmc9NQcACgkQzQJF27ox 2GdUvw/9FPPAT3koocRqsWg9XyzTHx/X9d2GQ4LnqUAdLD6QG2MG2ArjpJHJg++P PGlrgaGzOqztRz5ncmSVJltLvzN3p/lPzu37x4TIc6cDOUsojycX9hB0RMOyg90/ 8ZNYqYFmanBxSlTUaJNIXYRWYwNpluFMmmc8lvvTcnq9/xQN+21TspdZEpZd6SA3 R4M0kmRhS35EsvMT3ALUDxxp9CSB0QYshyo3GFFBan6WBxz+8qUQ92YaKHPur9k4 xV70l8kW1bL0btEO9G7jKbo6oMJlTnOgOYMs4yjm3XtqHPJW5ky+iGNnBc2HrIIx 1AmKGGVxxxKCyy0hYt12AVyiIrq9/woctT21BuXCGgvStss5rgBsC6z09KEqEmQi +ZPIgH4Q8ubYRrZLSm5i0CeRhsAjGCgZu3Z+Z/qOXJ0QZ37UK1vLPYn358Bx5yPy FhrEo+8uhw5eldt9Ug3MoylXEAIuZgLkm0lm1ta/bqZTGnBJENy+J72EUsjmf8bd L3ncIYLzym/VlhN+o/8jL2RPNoAKRizOD/ZycFLonL0QXUkFfGbkwB0oIB7vWcJQ KQDBNZRBYnXOLF7hcIuDQAixKvSS7ekw9mM7q/h41/D2ZRqaRnT5eI+DD6aaB2Yb Tgx/f6nGOmjALUDAMARfqwaYyEeinijDVX4yBEWqFpNrgK/5LYQ= =enrx -----END PGP SIGNATURE----- --JEG0QPm2//ZL56WB--