Implicit flow tables can't be listed

Implicit flow tables can't be listed

[Florian Westphal]

nft currently can't list implicit flow tables, e.g.:

 nft add rule ip filter forward flow { ip daddr counter }

... will work, and it shows up in

'nft list flow tables' as 'flow table __ft0' (or some other number) but

 nft list flow table filter __ft0
... will error out ('unexpected junk, expecting string').

We can either teach scanner.l that __ft{decstring} is a string,
or force users to always provide a name.

Any preference?

Thanks.

Re: Implicit flow tables can't be listed

[Pablo Neira Ayuso]

Hi Florian,

On Thu, Jun 16, 2016 at 12:29:01PM +0200, Florian Westphal wrote:
> nft currently can't list implicit flow tables, e.g.:
> 
>  nft add rule ip filter forward flow { ip daddr counter }
> 
> ... will work, and it shows up in
> 
> 'nft list flow tables' as 'flow table __ft0' (or some other number) but
> 
>  nft list flow table filter __ft0
> ... will error out ('unexpected junk, expecting string').
> 
> We can either teach scanner.l that __ft{decstring} is a string,
> or force users to always provide a name.
>
> Any preference?

How can we actually relate the rule with the flow table if we have
several anonymous flow tables?

More thoughts on flow tables thing. I think we should explore flow
table declarations support like:

table ip filter {
        flow table ft {
                ip saddr counter
                # content here
        }

        chain forward {
                type filter hook forward priority 0;
                flow @ft
        }

So we can dereference existing flow tables from rules.

This also provides a way to restore blacklist/whitelist in case we want
to save them into file and restore them later. The original idea is
that flow tables contain volatile information, but I think someone may
want to store the current state into file and restore it, eg. in case
it needs to reboot the system.

Moreover, the output of the list flow tables command in nft should be
parseable, as it is the case for the existing object listings.

This needs a bit of code update so we can get the listing working
properly (currently what Pablo Bermudo added is a bit of a hack just
to allow people inspect their content, but as I said in the nft 0.6
announcement, this output format is not stable).

Re: Implicit flow tables can't be listed

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> How can we actually relate the rule with the flow table if we have
> several anonymous flow tables?

nft list table filter
table ip filter {
        chain input {
                type filter hook input priority 0; policy accept;
                flow table __ft0 { ip saddr counter packets 0 bytes 0}
                flow table __ft1 { ip daddr counter packets 0 bytes 0}
        }

... so the internal name will be shown.

[..]

> This also provides a way to restore blacklist/whitelist in case we want
> to save them into file and restore them later. The original idea is
> that flow tables contain volatile information, but I think someone may
> want to store the current state into file and restore it, eg. in case
> it needs to reboot the system.

Agree.

Re: Implicit flow tables can't be listed

[Pablo Neira Ayuso]

On Wed, Jun 22, 2016 at 02:25:47PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > How can we actually relate the rule with the flow table if we have
> > several anonymous flow tables?
> 
> nft list table filter
> table ip filter {
>         chain input {
>                 type filter hook input priority 0; policy accept;
>                 flow table __ft0 { ip saddr counter packets 0 bytes 0}
>                 flow table __ft1 { ip daddr counter packets 0 bytes 0}
>         }
> 
> ... so the internal name will be shown.

OK, then enhance the scanner to catch __ and run tests to validate. I
don't think this break anything.