From deb978149aba32d2351a744e13902b0749855b42 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= Date: Wed, 22 Mar 2023 11:29:45 +0100 Subject: [PATCH] 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. --- src/quic_conn.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/quic_conn.c b/src/quic_conn.c index 60c8f7cab..ef2707c14 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);