From: Frédéric Lécaille <flecaille@haproxy.com>
Date: Wed, 22 Mar 2023 10:29:45 +0000 (+0100)
Subject: BUG/MINOR: quic: Missing max_idle_timeout initialization for the connection
X-Git-Tag: v2.8-dev7~129
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=deb978149aba32d2351a744e13902b0749855b42;p=thirdparty%2Fhaproxy.git

BUG/MINOR: quic: Missing max_idle_timeout initialization for the connection

This bug was revealed by handshakeloss interop tests (often with quiceh) where one
could see haproxy an Initial packet without TLS ClientHello message (only a padded
PING frame). In this case, as the ->max_idle_timeout was not initialized, the
connection was closed about three seconds later, and haproxy opened a new one with
a new source connection ID upon receipt of the next client Initial packet. As the
interop runner count the number of source connection ID used by the server to check
there were exactly 50 such IDs used by the server, it considered the test as failed.

So, the ->max_idle_timeout of the connection must be at least initialized
to the local "max_idle_timeout" transport parameter value to avoid such
a situation (closing connections too soon) until it is "negotiated" with the
client when receiving its TLS ClientHello message.

Must be backported to 2.7 and 2.6.
---

diff --git a/src/quic_conn.c b/src/quic_conn.c
index 60c8f7cab4..ef2707c14f 100644
--- a/src/quic_conn.c
+++ b/src/quic_conn.c
@@ -5435,6 +5435,10 @@ static struct quic_conn *qc_new_conn(const struct quic_version *qv, int ipv4,
 	                                    qc->scid.data, qc->scid.len, token_odcid))
 		goto err;
 
+	/* Initialize the idle timeout of the connection at the "max_idle_timeout"
+	 * value from local transport parameters.
+	 */
+	qc->max_idle_timeout = qc->rx.params.max_idle_timeout;
 	qc->wait_event.tasklet = tasklet_new();
 	if (!qc->wait_event.tasklet) {
 		TRACE_ERROR("tasklet_new() failed", QUIC_EV_CONN_TXPKT);