[PATCH v2 0/4] Reworks and improvements to TCP activity timers

newer
[PATCH 0/3] Miscellaneous minor...

older
Support for equivalent to slirp...

David Gibson

6 Feb 2026 6 Feb '26

7:17 a.m.

Here's a bunch of patches aimed at fixing bug 179, and reworking the currently broken inactivity timer along the way. I believe patches 1..2/4 are ready to go - I've tested them, and I'm happy with how they're behaving. Patches 3..4/4 I think are correct, but I've been getting bogged down in details trying to test them in the specific FIN_WAIT_2 situation that occurs in bug 179. I'm sending this out for comment, while I look at some other things to clear my head. Caveats: * Currently the inactivity timer uses an interval of 2h to match the intended behaviour of the existing non-working activity timeout. Arguably it should be much longer (several days), like the kernel NAT timeout for idle connection tracking. * This introduces two new fields in the connection structure, as the clock values for the two new timers. These are new 1-bit bool fields slotted into a 3-bit gap. Arguably these would be cleaner as new bits in the 'flags' field. However, since we only have one spare bit there at the moment, that would require some more complex reorganization which I didn't want to tackle right now. Changes in v2: * Set keepalive interval to 300s * Fix an inordinate number of typos and other cosmetic errors David Gibson (4): tcp: Remove non-working activity timeout mechanism tcp: Re-introduce inactivity timeouts based on a clock algorithm tcp: Extend tcp_send_flag() to send TCP keepalive segments tcp: Send TCP keepalive segments after a period of tap-side inactivity tcp.c | 118 ++++++++++++++++++++++++++++++++++++++----------- tcp.h | 6 ++- tcp_buf.c | 4 ++ tcp_conn.h | 5 +++ tcp_internal.h | 2 + tcp_vu.c | 3 ++ 6 files changed, 112 insertions(+), 26 deletions(-) -- 2.53.0

Show replies by date

David Gibson

6 Feb 6 Feb

7:17 a.m.

New subject: [PATCH v2 4/4] tcp: Send TCP keepalive segments after a period of tap-side inactivity

There are several circumstances in which a live, but idle TCP connection can be forgotten by a guest, with no "on the wire" indication that this has happened. The most obvious is if the guest abruptly reboots. A more subtle case can happen with a half-closed connection, specifically one in FIN_WAIT_2 state on the guest. A connection can, legitimately, remain in this state indefinitely. If however, a socket in this state is closed by userspace, Linux at least will remove the kernel socket after 60s (or as configured in the net.ipv4.tcp_fin_timeout sysctl). Because there's no on the wire indication in these cases, passt will pointlessly retain the connection in its flow table, at least until it is removed by the inactivity timeout after several hours. To avoid keeping connections around for so long in this state, add functionality to periodically send TCP keepalive segments to the guest if we've seen no activity on the tap interface. If the guest is no longer aware of the connection, it should respond with an RST which will let passt remove the stale entry. To do this we use a method similar to the inactivity timeout - a 1-bit page replacement / clock algorithm, but with a shorter interval, and only checking for tap side activity. Currently we use a 300s interval, meaning we'll send a keepalive after 5-10 minutes of (tap side) inactivity. Link: https://bugs.passt.top/show_bug.cgi?id=179 Signed-off-by: David Gibson --- tcp.c | 41 +++++++++++++++++++++++++++++++++++++++++ tcp.h | 2 ++ tcp_conn.h | 2 ++ 3 files changed, 45 insertions(+) diff --git a/tcp.c b/tcp.c index 09929ee9..f5dad1ee 100644 --- a/tcp.c +++ b/tcp.c @@ -206,6 +206,12 @@ * keepalives) will be removed between INACTIVITY_INTERVAL seconds and * 2*INACTIVITY_INTERVAL seconds after the last activity. * + * - KEEPALIVE_INTERVAL: if a connection has had no tap-side activity for an + * entire interval, send a tap-side keepalive. If the endpoint is no longer + * aware of the connection (due to a reboot, or a kernel timeout in FIN_WAIT_2 + * state) that should trigger an RST, so we won't keep track of connections + * that the guest endpoint no longer cares about. + * * Summary of data flows (with ESTABLISHED event) * ---------------------------------------------- * @@ -342,6 +348,7 @@ enum { #define RTO_INIT_AFTER_SYN_RETRIES 3 /* s, RFC 6298 */ #define INACTIVITY_INTERVAL 7200 /* s */ +#define KEEPALIVE_INTERVAL 300 /* s */ #define LOW_RTT_TABLE_SIZE 8 #define LOW_RTT_THRESHOLD 10 /* us */ @@ -2263,6 +2270,7 @@ int tcp_tap_handler(const struct ctx *c, uint8_t pif, sa_family_t af, } conn->inactive = false; + conn->tap_inactive = false; if (th->ack && !(conn->events & ESTABLISHED)) tcp_update_seqack_from_tap(c, conn, ntohl(th->ack_seq)); @@ -2884,6 +2892,38 @@ int tcp_init(struct ctx *c) return 0; } +/** + * tcp_keepalive() - Send keepalives for connections which need it + * @c: Execution context + * @now: Current timestamp + */ +static void tcp_keepalive(struct ctx *c, const struct timespec *now) +{ + union flow *flow; + + if (now->tv_sec - c->tcp.keepalive_run < KEEPALIVE_INTERVAL) + return; + + c->tcp.keepalive_run = now->tv_sec; + + flow_foreach(flow) { + struct tcp_tap_conn *conn = &flow->tcp; + + if (flow->f.type != FLOW_TCP) + continue; + + if (conn->tap_inactive) { + flow_dbg(conn, +"No tap activity for at least %us, send keepalive", + KEEPALIVE_INTERVAL); + tcp_send_flag(c, conn, KEEPALIVE); + } + + /* Ready to check for next interval */ + conn->tap_inactive = true; + } +} + /** * tcp_inactivity() - Scan for and close long-inactive connections * @c: Execution context @@ -2928,6 +2968,7 @@ void tcp_timer(struct ctx *c, const struct timespec *now) if (c->mode == MODE_PASTA) tcp_splice_refill(c); + tcp_keepalive(c, now); tcp_inactivity(c, now); } diff --git a/tcp.h b/tcp.h index e104d453..2739f309 100644 --- a/tcp.h +++ b/tcp.h @@ -38,6 +38,7 @@ extern bool peek_offset_cap; * @rto_max: Maximum retry timeout (in s) * @syn_retries: SYN retries using exponential backoff timeout * @syn_linear_timeouts: SYN retries before using exponential backoff timeout + * @keepalive_run: Time we last issued tap-side keepalives * @inactivity_run: Time we last scanned for inactive connections */ struct tcp_ctx { @@ -48,6 +49,7 @@ struct tcp_ctx { int rto_max; uint8_t syn_retries; uint8_t syn_linear_timeouts; + time_t keepalive_run; time_t inactivity_run; }; diff --git a/tcp_conn.h b/tcp_conn.h index 7197ff63..83bb6fb1 100644 --- a/tcp_conn.h +++ b/tcp_conn.h @@ -16,6 +16,7 @@ * @ws_from_tap: Window scaling factor advertised from tap/guest * @ws_to_tap: Window scaling factor advertised to tap/guest * @tap_mss: MSS advertised by tap/guest, rounded to 2 ^ TCP_MSS_BITS + * @tap_inactive: No tap activity within the current KEEPALIVE_INTERVAL * @inactive: No activity within the current INACTIVITY_INTERVAL * @sock: Socket descriptor number * @events: Connection events, implying connection states @@ -58,6 +59,7 @@ struct tcp_tap_conn { (conn->rtt_exp = MIN(RTT_EXP_MAX, ilog2(MAX(1, rtt / RTT_STORE_MIN)))) #define RTT_GET(conn) (RTT_STORE_MIN << conn->rtt_exp) + bool tap_inactive :1; bool inactive :1; int sock :FD_REF_BITS; -- 2.53.0

Stefano Brivio

25 Feb 25 Feb

7:15 a.m.

On Fri, 6 Feb 2026 17:17:35 +1100 David Gibson wrote:

...

Here's a bunch of patches aimed at fixing bug 179, and reworking the currently broken inactivity timer along the way.

I believe patches 1..2/4 are ready to go - I've tested them, and I'm happy with how they're behaving. Patches 3..4/4 I think are correct, but I've been getting bogged down in details trying to test them in the specific FIN_WAIT_2 situation that occurs in bug 179.

I just tested things manually by cycling guest interfaces and checking that keepalives come and eventually cause connection resets, as well as that the activity timeout (shortened via define) triggers after the expected time. It's not great but I couldn't figure out a way to simulate the issue with a single namespace test (without any connecting interface that can be brought down), and simulating this with multiple namespaces connected via veth looks doable, but not easy to integrate with the existing tests. Meanwhile the reporter of https://bugs.passt.top/show_bug.cgi?id=179 confirms this series solves the issue, and delaying this further doesn't sound like a good idea, so I went ahead and finally applied this, fixing a trivial conflict with 812cdb802c6e ("tcp: Move tap header update out of tcp_fill_headers()") on the way. -- Stefano

David Gibson

2 Mar 2 Mar

2:26 a.m.

On Wed, Feb 25, 2026 at 07:15:45AM +0100, Stefano Brivio wrote:

...

On Fri, 6 Feb 2026 17:17:35 +1100 David Gibson wrote:

...
Here's a bunch of patches aimed at fixing bug 179, and reworking the currently broken inactivity timer along the way.

I believe patches 1..2/4 are ready to go - I've tested them, and I'm happy with how they're behaving. Patches 3..4/4 I think are correct, but I've been getting bogged down in details trying to test them in the specific FIN_WAIT_2 situation that occurs in bug 179.

I just tested things manually by cycling guest interfaces and checking that keepalives come and eventually cause connection resets, as well as that the activity timeout (shortened via define) triggers after the expected time.

Nice.

...

It's not great but I couldn't figure out a way to simulate the issue with a single namespace test (without any connecting interface that can be brought down), and simulating this with multiple namespaces connected via veth looks doable, but not easy to integrate with the existing tests.

Right. I think it can be tested without bouncing interfaces at all - however it needs quite specific behaviour from both the client and the server. I couldn't figure out a way to convince socat to do what I wanted, so it would probably need custom endpoint programs.

...

Meanwhile the reporter of https://bugs.passt.top/show_bug.cgi?id=179 confirms this series solves the issue, and delaying this further doesn't sound like a good idea, so I went ahead and finally applied this, fixing a trivial conflict with 812cdb802c6e ("tcp: Move tap header update out of tcp_fill_headers()") on the way.

Makes sense to me. -- 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

Age (days ago)

Last active (days ago)

List overview

Download

3 comments

2 participants

participants (2)

David Gibson
Stefano Brivio