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
Subject: Re: [PATCH nf-next 0/4] netfilter: offload a TCP flow whose reply is never seen
Date: Fri, 11 Sep 2026 16:16:15 +0200 [thread overview]
Message-ID: <aqQNL0qIkmFNGANg@chamomile> (raw)
In-Reply-To: <aqQLqwJVRROZ-cvH@chamomile>
On Fri, Sep 11, 2026 at 04:09:51PM +0200, Pablo Neira Ayuso wrote:
> Hi Julius,
>
> On Fri, Sep 11, 2026 at 12:10:04PM +0000, Julius Bairaktaris wrote:
> > Hi Pablo,
> >
> > thanks for taking your time to review.
> >
> > > conntrack needs to see packets in both directions, are you assuming a
> > > packet-based load balancer in front of it?
> >
> > No, an asymmetric route is in front of it, with two subnets sharing one
> > L2 segment and the server answering over that link, so the router only
> > ever sees one direction.
>
> I see this requirement to support asymmetric path keeps coming, but
> how hard is really to maintain this TCP state machine to deal with all
> possible scenarios? ie. invalid transitions, retransmissions, etc.
> this all without having access to full TCP connection. Is it that you
> need NAT and the stateless NAT in nftables does not fulfill your
> requirements?
I can reply myself, you're targetting at offloading this flow via the
flowtable.
Let me take a look what can be done here for this assymetric case.
prev parent reply other threads:[~2026-09-11 14:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 9:00 [PATCH nf-next 0/4] netfilter: offload a TCP flow whose reply is never seen Julius Bairaktaris
2026-09-10 9:00 ` [PATCH nf-next 1/4] netfilter: conntrack: pick up a TCP flow whose SYN was never answered Julius Bairaktaris
2026-09-10 9:00 ` [PATCH nf-next 2/4] netfilter: flowtable: promote a flow offloaded in one direction only Julius Bairaktaris
2026-09-10 9:00 ` [PATCH nf-next 3/4] netfilter: nft_flow_offload: offload a TCP flow that has no reply Julius Bairaktaris
2026-09-10 9:00 ` [PATCH nf-next 4/4] selftests: netfilter: cover a TCP flow whose reply is never seen Julius Bairaktaris
2026-09-11 11:41 ` [PATCH nf-next 0/4] netfilter: offload " Pablo Neira Ayuso
2026-09-11 12:10 ` Julius Bairaktaris
2026-09-11 14:09 ` Pablo Neira Ayuso
2026-09-11 14:16 ` Pablo Neira Ayuso [this message]
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=aqQNL0qIkmFNGANg@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=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.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.