From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Julius Bairaktaris <julius@bairaktaris.de>
Cc: netfilter-devel@vger.kernel.org, kadlec@netfilter.org,
fw@strlen.de, coreteam@netfilter.org, netdev@vger.kernel.org,
geldot@protonmail.com, shuah@kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH nf-next v2 0/4] netfilter: offload a TCP flow whose reply is never seen
Date: Sun, 18 Oct 2026 03:42:58 +0200 [thread overview]
Message-ID: <atQkIj262kQ0B0VZ@chamomile> (raw)
In-Reply-To: <20261004171628.3544978-1-julius@bairaktaris.de>
On Sun, Oct 04, 2026 at 07:16:24PM +0200, Julius Bairaktaris wrote:
> A router that sees only one direction of a TCP connection, because the
> reply takes another path, cannot offload it: conntrack marks the
> client's ACK after the SYN invalid, and the flowtable only takes assured
> TCP connections. The setup this comes from is two subnets on one L2
> segment, with the server answering over the shared segment.
>
> The series adds no TCP state:
> - patch 1 hands that ACK to the existing loose pickup in tcp_new(),
> gated by nf_conntrack_tcp_loose, as if the SYN had not been seen
> - patch 2 keeps the reply direction of such a flow on the classic path
> until the connection is assured, as act_ct does for UDP
> - patch 3 offloads the connection in the original direction and caps
> the timeout handed back to conntrack at UNACK, as
> nf_conntrack_tcp_packet() does
> - patch 4 adds a selftest, which fails without patches 1 to 3
>
> Pablo, on v1 you asked how TCP tracking copes without the reply
> direction, and guessed right that the goal is flowtable offload. The
> connection is tracked like a loose mid-stream pickup today: window
> checks are off in both directions, and a FIN or RST still takes the
> flow off the flowtable.
Yes, but posting it again does not get me anywhere.
This series are a no-go in this approach.
LLM is offering a quick-fix/workaround to make things work.
Please, given we are discussing one series of you quite recently...
let's handle one thing at a time. Once that gets merged, let's look at
the next.
> This series was written with the help of an AI coding assistant. I have
> reviewed and tested it.
>
> Changes in v2:
> - patch 2: the XDP flowtable lookup does not return the held reply tuple
> - patch 3: cap the conntrack timeout at UNACK while no reply was seen
> - rebased onto nf-next
>
> v1: https://lore.kernel.org/netfilter-devel/20260910090052.2034970-1-julius@bairaktaris.de/
>
> Gary Dotzler (2):
> netfilter: conntrack: pick up a TCP flow whose SYN was never answered
> netfilter: nft_flow_offload: offload a TCP flow that has no reply
>
> Julius Bairaktaris (2):
> netfilter: flowtable: promote a flow offloaded in one direction only
> selftests: netfilter: cover a TCP flow whose reply is never seen
>
> include/net/netfilter/nf_conntrack_l4proto.h | 9 +++
> net/netfilter/nf_conntrack_proto_tcp.c | 16 ++++
> net/netfilter/nf_flow_table_bpf.c | 4 +
> net/netfilter/nf_flow_table_core.c | 5 ++
> net/netfilter/nf_flow_table_ip.c | 26 +++++++
> net/netfilter/nft_flow_offload.c | 6 +-
> .../selftests/net/netfilter/nft_flowtable.sh | 75 +++++++++++++++++++
> 7 files changed, 139 insertions(+), 2 deletions(-)
>
>
> base-commit: 87b80c2f6b05cad9f0ff9136709c62a0f59923e3
> --
> 2.53.0
>
>
next prev parent reply other threads:[~2026-10-18 1:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 17:16 [PATCH nf-next v2 0/4] netfilter: offload a TCP flow whose reply is never seen Julius Bairaktaris
2026-10-04 17:16 ` [PATCH nf-next v2 1/4] netfilter: conntrack: pick up a TCP flow whose SYN was never answered Julius Bairaktaris
2026-10-18 1:36 ` Pablo Neira Ayuso
2026-10-04 17:16 ` [PATCH nf-next v2 2/4] netfilter: flowtable: promote a flow offloaded in one direction only Julius Bairaktaris
2026-10-04 17:16 ` [PATCH nf-next v2 3/4] netfilter: nft_flow_offload: offload a TCP flow that has no reply Julius Bairaktaris
2026-10-04 17:16 ` [PATCH nf-next v2 4/4] selftests: netfilter: cover a TCP flow whose reply is never seen Julius Bairaktaris
2026-10-17 10:37 ` [PATCH nf-next v2 0/4] netfilter: offload " Julius Bairaktaris
2026-10-18 1:42 ` Pablo Neira Ayuso [this message]
2026-10-18 1:54 ` Julius Bairaktaris
2026-10-18 2:00 ` Pablo Neira Ayuso
2026-10-18 2:02 ` Julius Bairaktaris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atQkIj262kQ0B0VZ@chamomile \
--to=pablo@netfilter.org \
--cc=coreteam@netfilter.org \
--cc=fw@strlen.de \
--cc=geldot@protonmail.com \
--cc=julius@bairaktaris.de \
--cc=kadlec@netfilter.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.