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.
