From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Steven Haigh <netwiz@crc.id.au>
Cc: netfilter@vger.kernel.org
Subject: Re: aarch64 - netlink: Error: Could not process rule: No buffer space available
Date: Wed, 4 Mar 2026 01:53:11 +0100 [thread overview]
Message-ID: <aaeCd1rZsttYRVBf@chamomile> (raw)
In-Reply-To: <5e92cfab-a593-4679-8df2-abb8b9e32bad@crc.id.au>
On Wed, Mar 04, 2026 at 11:49:41AM +1100, Steven Haigh wrote:
> On 4/3/26 11:42, Pablo Neira Ayuso wrote:
> > On Wed, Mar 04, 2026 at 11:34:39AM +1100, Steven Haigh wrote:
> > > On 4/3/26 11:17, Pablo Neira Ayuso wrote:
> > > > On Wed, Mar 04, 2026 at 01:02:14AM +0100, Pablo Neira Ayuso wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, Mar 04, 2026 at 10:36:20AM +1100, Steven Haigh wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > Firstly, please CC me in replies as I'm not subscribed to the list.
> > > > > >
> > > > > > I am currently loading some named sets into nftables using the following
> > > > > > configuration:
> > > > > >
> > > > > > set au-ipv4 {
> > > > > > type ipv4_addr
> > > > > > flags interval
> > > > > > auto-merge
> > > > > > elements = { $AU.ipv4 }
> > > > > > }
> > > > > >
> > > > > > set au-ipv6 {
> > > > > > type ipv6_addr
> > > > > > flags interval
> > > > > > auto-merge
> > > > > > elements = { $AU.ipv6 }
> > > > > > }
> > > > > >
> > > > > > These sets are loaded in the config via:
> > > > > > include "/etc/nftables/firewall/geo-nft/countrysets/AU.ipv4";
> > > > > > include "/etc/nftables/firewall/geo-nft/countrysets/AU.ipv6";
> > > > > >
> > > > > > The files are created using the geo-nft.sh script here:
> > > > > > https://raw.githubusercontent.com/wirefalls/geo-nft/main/geo-nft.sh
> > > > > >
> > > > > > When loading these, I get the following fatal error:
> > > > > > netlink: Error: Could not process rule: No buffer space available
> > > >
> > > > Just to be sure and discard something simple.
> > > >
> > > > Maybe you made a mistake in your ruleset in the aarch64 box? With lots
> > > > of errors coming from the kernel, older userspace nftables versions
> > > > report ENOBUFS.
> > > >
> > > > Try loading AU.ipv4 and AU.ipv6 with only one element to see if
> > > > userspace reports a different error.
> > > >
> > > > commit 47e9aaf0227daf16f43a7442e1dceae8851817a5
> > > > Author: Pablo Neira Ayuso <pablo@netfilter.org>
> > > > Date: Tue Aug 26 10:09:13 2025 +0200
> > > > mnl: continue on ENOBUFS errors when processing batch
> > > > A user reports that:
> > > > nft -f ruleset.nft
> > > > fails with:
> > > > netlink: Error: Could not process rule: No buffer space available
> > > > This was triggered by:
> > > > table ip6 fule {
> > > > set domestic_ip6 {
> > > > type ipv6_addr
> > > > flags dynamic,interval
> > > > elements = $domestic_ip6
> > > > }
> > > > chain prerouting {
> > > > type filter hook prerouting priority 0;
> > > > ip6 daddr @domestic_ip6 counter
> > > > }
> > > > }
> > > > where $domestic_ip6 contains a large number of IPv6 addresses.
> > > > This set declaration is not supported currently, because dynamic sets
> > > > with intervals are not supported, then every IPv6 address that is added
> > > > triggers an error, overruning the userspace socket buffer with lots of
> > > > NLMSG_ERROR messages (or too big NLMSG_ERROR message to fit into the
> > > > socket buffer)
> > >
> > > --snip--
> > >
> > > Interesting.
> > >
> > > I have noticed that if I split the set into multiple 'chunks', then the set
> > > can be populated properly.
> > >
> > > As an example, this crude claude code authored script here does function as
> > > expected and the entire set is loaded successfully:
> > > https://lamp.crc.id.au/paste/e0e9DD01E48E46e27F5ad1bc0e/
> >
> > Unfortunately, I cannot reach this link.
>
> Apologies - its behind the firewall that I'm debugging :)
>
> Mirrored here: https://pastebin.com/iTa9XRCb
This is insane:
while IFS= read -r line; do
...
echo "add element $TABLE_FAMILY $TABLE_NAME $set_name { $batch }" | nft -f -
this is one transaction per command.
This is as bad as a shell script with explicit iptables invocations,
one per line. This is an antipattern.
next prev parent reply other threads:[~2026-03-04 0:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 23:36 aarch64 - netlink: Error: Could not process rule: No buffer space available Steven Haigh
2026-03-04 0:02 ` Pablo Neira Ayuso
2026-03-04 0:17 ` Pablo Neira Ayuso
2026-03-04 0:34 ` Steven Haigh
2026-03-04 0:42 ` Pablo Neira Ayuso
2026-03-04 0:49 ` Steven Haigh
2026-03-04 0:53 ` Pablo Neira Ayuso [this message]
2026-03-04 1:05 ` Steven Haigh
2026-03-04 1:17 ` Pablo Neira Ayuso
2026-03-04 0:19 ` Steven Haigh
2026-03-04 0:35 ` Pablo Neira Ayuso
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=aaeCd1rZsttYRVBf@chamomile \
--to=pablo@netfilter.org \
--cc=netfilter@vger.kernel.org \
--cc=netwiz@crc.id.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox