On Thu, Sep 19, 2019 at 11:24:42AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > On Wed, Sep 18, 2019 at 04:42:35PM +0200, Florian Westphal wrote:
> > > Laura Garcia <nevola@xxxxxxxxx> wrote:
> > > > > Following example loads fine:
> > > > > table ip NAT {
> > > > > set set1 {
> > > > > type ipv4_addr
> > > > > size 64
> > > > > flags dynamic,timeout
> > > > > timeout 1m
> > > > > }
> > > > >
> > > > > chain PREROUTING {
> > > > > type nat hook prerouting priority -101; policy accept;
> > > > > }
> > > > > }
> > > > >
> > > > > But adding/using this set doesn't work:
> > > > > nft -- add rule NAT PREROUTING tcp dport 80 ip saddr @set1 counter
> > > > > Error: Could not process rule: Operation not supported
> > > >
> > > > If this set is only for matching, 'dynamic' is not required.
> > >
> > > I know, and the example above works if the 'dynamic' flag is omitted.
> >
> > Looks like a kernel bug, kernel is selecting the fixed size hash with
> > the dynamic flag. That should not happen.
>
> No, it selects the rhashtable one -- its the only one that sets
> NFT_SET_EVAL.
>
> > > > > The rule add is rejected from the lookup expression (nft_lookup_init)
> > > > > which has:
> > > > >
> > > > > if (set->flags & NFT_SET_EVAL)
> > > > > return -EOPNOTSUPP;
>
> ... and thats the reason why it won't work. "dynamic" flag disables
> lookup expression for the given set.
>
> I can't remove the if () because that would make it possible to lookup
> for meter-type sets.
Why is this a problem? meter-set are basically a set with a
counter/quota/etc... that is created from the packet path. It should
be possible to make lookups on the content of this set.
I think we can just check instead from nft_lookup if there is an
extension in this then, instead of checking for the NFT_SET_EVAL flag
to fix this. Hence, you can make lookups on dynamic sets, but not on
dynamic sets with extensions.
