Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: "Lars Noodén" <lars.nooden@gmx.com>, f@calendula
Cc: Linux Netfilter Users List <netfilter@vger.kernel.org>
Subject: Re: Dynamically appending addresses to a named set
Date: Thu, 13 Mar 2025 09:59:11 +0100	[thread overview]
Message-ID: <Z9KeXyPhYJHsXFqg@calendula> (raw)
In-Reply-To: <cd939795-b632-4eba-9ff0-c003c4419ba0@gmx.com>

On Thu, Mar 13, 2025 at 06:31:03AM +0200, Lars Noodén wrote:
> Thanks.
> 
> On 3/12/25 21:44, Kerin Millar wrote:
> > I suspect that your set has been declared with the "interval" flag
> > in effect, in which case updates from the packet path are not
> > allowed. As far as I can tell, this constraint is undocumented.
> 
> Yes, it is the case that the interval flag has been set.  It seems that
> the interval flag necessary when the set shall contain a mixture of
> single IPv4 addresses and subnets with elements:
> 
> 	"Error: You must add 'flags interval' to your
> 	 set declaration if you want to add prefix elements"
> 
> and with auto-merge:
> 
> 	"Error: auto-merge only works with interval sets"
> 
> It is necessary to have auto-merge since the individual IPv4 addresses
> and subnets get added in an unpredictable manner and may overlap.
> 
> On 3/13/25 00:06, Pablo Neira Ayuso wrote:
> > The ruleset above provides sufficient context to infer that the
> > dynamic flag is needed, but that might not be the case in all
> > circunstances. The dynamic flag cannot be inferred in all cases like
> > the one above.
> > 
> > Without Lars' set declaration, the question is incomplete and it is
> > not easy to answer.
> 
> The following is basically the set up:
> 
> table ip foo {
>         set bar {
>                 type ipv4_addr
>                 flags interval
>                 auto-merge
>                 elements = { 192.168.2.0/24 }
>         }
> 	chain input {}
> }
> 
> The two important parts to retain are auto-merge and pre-defined
> elements (and be able to add to the elements later).

which together with your previous rule means that:

# nft add rule foo input tcp dport 22 counter add @bar { ip saddr }
Error: Could not process rule: Operation not supported
add rule foo input tcp dport 22 counter add @bar { ip saddr }
                                        ^^^^^^^^^^^^^^^^^^^^^

reports EOPNOTSUP because interval sets do not currently support
updates from the packet path.

  reply	other threads:[~2025-03-13  8:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-12 16:08 Dynamically appending addresses to a named set Lars Noodén
2025-03-12 19:44 ` Kerin Millar
2025-03-12 19:48   ` Pablo Neira Ayuso
2025-03-12 21:50     ` Kerin Millar
2025-03-12 22:06       ` Pablo Neira Ayuso
2025-03-13  4:31         ` Lars Noodén
2025-03-13  8:59           ` Pablo Neira Ayuso [this message]
2025-03-14  6:12             ` Lars Noodén

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=Z9KeXyPhYJHsXFqg@calendula \
    --to=pablo@netfilter.org \
    --cc=f@calendula \
    --cc=lars.nooden@gmx.com \
    --cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox