From: Florian Westphal <fw@strlen.de>
To: Joshua Lant <joshualant@googlemail.com>
Cc: netfilter-devel@vger.kernel.org, fw@strlen.de
Subject: Re: iptables: compiling with kernel headers
Date: Thu, 8 Aug 2024 13:41:16 +0200 [thread overview]
Message-ID: <20240808114116.GC20589@breakpoint.cc> (raw)
In-Reply-To: <20240808095901.2844386-1-joshualant@gmail.com>
Joshua Lant <joshualant@googlemail.com> wrote:
> > Why are you interested in getting iptables to work?
> >
> > It would be better to ensure that nftables is working properly; unlike
> > with xtables the kernel representation is hidden from userspace.
>
> Sorry I should have been clear initially, I am trying to compile using nftables.
No, I was talking about:
https://git.netfilter.org/nftables/
which doesn't use any of the old xtables structures and
is not supposed to have any 'binary blobs' passed between
kernel and userland.
iptables-nft still uses some parts of xtables, most of the
matches and targets are handled this way, and binary blob is
passed to kernel via netlink. See net/netfilter/nft_compat.c
Admittingly, its less bad than the get/setsockopt format, but you've
already encountered things like include/uapi/linux/netfilter/xt_TEE.h
As for a way foward, there are several options:
1. "unsupported, use native nft binary"
2. what you did: force pointers to be sizeof(unsigned long), they
aren't used by userland, they are placeholders for kernel only
3. Once https://patchwork.ozlabs.org/project/netfilter-devel/patch/20240731222703.22741-8-phil@nwl.cc/
discussion is resolved, aggressively convert itpables-nft to
prefer native nft expressions instead of the nft_compat proxy.
3) is definitely a lot more work than 2).
Furthermore iptables-nft cannot be made a full nft client because
iptables syntax lacks aequivalents for native nft constructs like
jump maps or sets, so users cannot mix nft and iptables-nft anyway.
Personally I think it would be better to let iptables move
to maintenance only mode and let it die rather than continue
to spending time on it, but this is the minority opinion so far.
next prev parent reply other threads:[~2024-08-08 12:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240807162203.GA22962 () breakpoint ! cc>
2024-08-08 9:59 ` iptables: compiling with kernel headers Joshua Lant
2024-08-08 11:41 ` Florian Westphal [this message]
2024-08-07 14:36 josh lant
2024-08-07 16:22 ` Florian Westphal
2024-08-07 17:06 ` Phil Sutter
2024-08-08 11:08 ` Joshua Lant
2024-08-08 13:21 ` Phil Sutter
2024-08-07 19:18 ` Jan Engelhardt
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=20240808114116.GC20589@breakpoint.cc \
--to=fw@strlen.de \
--cc=joshualant@googlemail.com \
--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.