Metering is not working with dynamic sets on nft v0.9.2

Metering is not working with dynamic sets on nft v0.9.2

[darius]

[-- Attachment #1.1: Type: text/plain, Size: 1097 bytes --]

Hello,
I was using meters by using 'meter' keyword, but apparently it is now
obsolete. So, I have decided to update rules and use dynamic sets
instead. For some reason I'm getting an error stating that rule is not
supported. Here is what was working before and still works:

ct state new meter mymeter { ip saddr timeout 30s limit rate over
50/second burst 50 packets } counter drop

Then I have tried to update this rule to the following:

...
set mymeter{
    type ipv4_addr; flags timeout, dynamic;
}
...
ct state new add @mymeter { ip saddr timeout 30s limit rate over
50/second burst 50 packets } counter drop

In this case nft throws fault message:

root@HOMEROUTER:/etc/config# /etc/init.d/firewall reload
/etc/config/ruleset.nft:416:9-187: Error: Could not process rule: Not
supported
        ct state new add @mymeter { ip saddr timeout 30s limit rate over
50/second burst 50 packets } counter drop

I'm running OpenWRT, kernel v4.14.167, nft v.0.9.2
Could anyone help to find out what I'm doing wrong? It seems that I did
it according to wiki.

Regards


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Metering is not working with dynamic sets on nft v0.9.2

[ѽ҉ᶬḳ℠]

On 06/02/2020 22:42, darius wrote:
> Hello,
> I was using meters by using 'meter' keyword, but apparently it is now
> obsolete.

If not mistaken the intention is to replace meter with native set / map 
syntax but meter not yet being depreciated/retired.


> So, I have decided to update rules and use dynamic sets
> instead. For some reason I'm getting an error stating that rule is not
> supported. Here is what was working before and still works:
>
> ct state new meter mymeter { ip saddr timeout 30s limit rate over
> 50/second burst 50 packets } counter drop
>
> Then I have tried to update this rule to the following:
>
> ...
> set mymeter{
>      type ipv4_addr; flags timeout, dynamic;
> }
> ...
> ct state new add @mymeter { ip saddr timeout 30s limit rate over
> 50/second burst 50 packets } counter drop
>
> In this case nft throws fault message:
>
> root@HOMEROUTER:/etc/config# /etc/init.d/firewall reload
> /etc/config/ruleset.nft:416:9-187: Error: Could not process rule: Not
> supported
>          ct state new add @mymeter { ip saddr timeout 30s limit rate over
> 50/second burst 50 packets } counter drop
>
> I'm running OpenWRT, kernel v4.14.167, nft v.0.9.2
> Could anyone help to find out what I'm doing wrong? It seems that I did
> it according to wiki.
>
> Regards
>

Are NFT SETS otherwise working? If so then probably it is due to the 
inhabitation of the kernel version 4.14.x, least my understanding is 
that some SETS related features are only available as of kernel 4.15 | 4.18.

If SETS however generally printing the error then it likely would be 
caused by an unset kernel build configuration flag.

Re: Metering is not working with dynamic sets on nft v0.9.2

[Florian Westphal]

ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> On 06/02/2020 22:42, darius wrote:
> > Hello,
> > I was using meters by using 'meter' keyword, but apparently it is now
> > obsolete.

Not really, it will continue to work.

> If not mistaken the intention is to replace meter with native set / map
> syntax but meter not yet being depreciated/retired.

Yes.

> > root@HOMEROUTER:/etc/config# /etc/init.d/firewall reload
> > /etc/config/ruleset.nft:416:9-187: Error: Could not process rule: Not
> > supported
> >          ct state new add @mymeter { ip saddr timeout 30s limit rate over
> > 50/second burst 50 packets } counter drop
> > 
> > I'm running OpenWRT, kernel v4.14.167, nft v.0.9.2
> > Could anyone help to find out what I'm doing wrong? It seems that I did
> > it according to wiki.

Its a kernel bug.  The kernel picks the wrong set backend on 4.14, so
when it sees the rule (which requires a set that supports updates) it
will fail.

Contine to use mter syntax if that works for you.

Re: Metering is not working with dynamic sets on nft v0.9.2

[Darius]

Ok, I'll keep using 'meter' keywork. Sets are working just perfectly, all sets instructions works as well.

But do you know if it is only 4.14 kernel affected? Is there any bug report and patch available for this issue for kernel 4.14?

Regards

> On February 7, 2020 11:17 AM Florian Westphal <fw@strlen.de> wrote:
> 
>  
> ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> > On 06/02/2020 22:42, darius wrote:
> > > Hello,
> > > I was using meters by using 'meter' keyword, but apparently it is now
> > > obsolete.
> 
> Not really, it will continue to work.
> 
> > If not mistaken the intention is to replace meter with native set / map
> > syntax but meter not yet being depreciated/retired.
> 
> Yes.
> 
> > > root@HOMEROUTER:/etc/config# /etc/init.d/firewall reload
> > > /etc/config/ruleset.nft:416:9-187: Error: Could not process rule: Not
> > > supported
> > >          ct state new add @mymeter { ip saddr timeout 30s limit rate over
> > > 50/second burst 50 packets } counter drop
> > > 
> > > I'm running OpenWRT, kernel v4.14.167, nft v.0.9.2
> > > Could anyone help to find out what I'm doing wrong? It seems that I did
> > > it according to wiki.
> 
> Its a kernel bug.  The kernel picks the wrong set backend on 4.14, so
> when it sees the rule (which requires a set that supports updates) it
> will fail.
> 
> Contine to use mter syntax if that works for you.

Re: Metering is not working with dynamic sets on nft v0.9.2

[Florian Westphal]

Darius <dram@mailbox.org> wrote:
> Ok, I'll keep using 'meter' keywork. Sets are working just perfectly, all sets instructions works as well.
> 
> But do you know if it is only 4.14 kernel affected? Is there any bug report and patch available for this issue for kernel 4.14?

No idea.  I suspect its this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=acab713177377d9e0889c46bac7ff0cfb9a90c4d

Re: Metering is not working with dynamic sets on nft v0.9.2

[Darius]

Thanks! Will investigate a bit

Regards

> On February 7, 2020 12:06 PM Florian Westphal <fw@strlen.de> wrote:
> 
>  
> Darius <dram@mailbox.org> wrote:
> > Ok, I'll keep using 'meter' keywork. Sets are working just perfectly, all sets instructions works as well.
> > 
> > But do you know if it is only 4.14 kernel affected? Is there any bug report and patch available for this issue for kernel 4.14?
> 
> No idea.  I suspect its this patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=acab713177377d9e0889c46bac7ff0cfb9a90c4d

Re: Metering is not working with dynamic sets on nft v0.9.2

[darius]

[-- Attachment #1.1: Type: text/plain, Size: 761 bytes --]

I have checked link provided by you. This patch is already implemented
on 4.14 kernel that runs on OpenWRT, but that does not help with the
error. I still have fault.
Any other ideas where to check? Just would be nice to find where is problem.

Regards

On 07.02.2020 12.06, Florian Westphal wrote:
> Darius <dram@mailbox.org> wrote:
>> Ok, I'll keep using 'meter' keywork. Sets are working just perfectly, all sets instructions works as well.
>>
>> But do you know if it is only 4.14 kernel affected? Is there any bug report and patch available for this issue for kernel 4.14?
> 
> No idea.  I suspect its this patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=acab713177377d9e0889c46bac7ff0cfb9a90c4d
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Metering is not working with dynamic sets on nft v0.9.2

[Florian Westphal]

darius <dram@mailbox.org> wrote:
> I have checked link provided by you. This patch is already implemented
> on 4.14 kernel that runs on OpenWRT, but that does not help with the
> error. I still have fault.
> Any other ideas where to check? Just would be nice to find where is problem.

No.  If you know some C, edit net/netfilter/nf_tables.c, search for
nft_select_set_ops() and check which set type is picked.

ops needs to be "nft_set_rhash_type", thats the only one where
ops->update is non-NULL.