On Wed, 12 Mar 2025, at 7:48 PM, Pablo Neira Ayuso wrote:
> On Wed, Mar 12, 2025 at 07:44:25PM +0000, Kerin Millar wrote:
>> On Wed, 12 Mar 2025, at 4:08 PM, Lars Noodén wrote:
>> > Hello,
>> >
>> > In NFTables, I have created a named set called 'bar' in the chain input
>> > in the table foo. I can add elements to the set manually,
>> >
>> > # nft add element ip foo bar { 192.168.2.2 }
>> >
>> > However, I am not able to guess the syntax to have a regular NFTables
>> > rule do the appending automatically. I've tried a lot of permutations
>> > of the following, but always with fatal errors,
>> >
>> > # 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 }
>>
>> For the kernel to raise ENOTSUP does not indicate an error of syntax. The bytecode intended for the nftables VM will already have been compiled at this point.
>>
>> 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.
>
> Maybe Lars forgot to set on the flags dynamic;
Not to go off on a tangent but that was my initial thought. Yet, neglecting to specify the "dynamic" flag does not seem able to cause the error that Lars describes.
# cat test.nft
flush ruleset
table ip foo {
set bar { type ipv4_addr; }
chain input {}
}
# nft -f test.nft
# nft 'add rule foo input tcp dport 22 counter add @bar { ip saddr }'; echo "$?"
0
That's with nftables v1.1.1 and Linux 6.12.13. Ultimately, the set becomes a dynamic one, even though it was not declared to that effect. I find it surprising because:
- the behaviour of the implementation directly contradicts the manual
- it seems difficult to fathom, predict and explain the behaviour
- it casts doubt on the purpose of the flag (where is it even useful to declare it?)
I wonder, also, how nft(8) can possibly be assured of my intent in a situation such as this. Imagine a scenario in which the admin adjusts a set so as to be non-dynamic and forgets to remove a rule that updates from the packet path prior to reloading a ruleset. Could it not simply abort upon encountering the rule and require for the admin to resolve the innate contradiction?
Or, is "dynamic" destined to become a historical artifact and be retained only for the purposes of backwards-compatibility?
--
Kerin Millar
