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).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
