Pablo Neira Ayuso <[email protected]> wrote:
> > Changes since v1:
> > - Apply same fix to net/bridge/netfilter/nft_meta_bridge.c as well.
> >
> > Changes since v2:
> > - Limit this fix to address only expressions returning an interface
> > index or name. As Florian correctly criticized, these changes may be
> > problematic as they tend to change nftables' behaviour. Hence fix only
> > the cases needed to establish iptables-nft compatibility.
>
> This leaves things in an inconsistent situation.
>
> What's the concern here? Matching iifgroup/oifgroup from the wrong
> packet path?
There is no solution for this problem -- thats the core issue.
Purely from a technical p.o.v., we're asking to match oif, but its not
there, so to me, the current behaviour is the right one: break, because
we can't provide the requested information.
On the other hand, this makes things rather un-intuitive when asking for
not eq "foo" -- and not getting a match.
Plus, there is the "compat" angle.
For iifname and ifindex we're safe because "" is not a valid interface
name and 0 is not a valid ifindex. But for everything else, I'd be
extra careful.
One alternative is to add the "compat" netlink attribute for
iptables-nft and only change behaviour for iptables-nft sake.
But I feel that noone has real evidence in this matter, just hunches.
If in doubt, I would even prefer to keep things as-is and add the
compat attr for meta so we get iptables-nft to behave like
iptables-legacy and keep nft as-is.
This will become relevant once we get a saner behaviour for non-matching
sets (such as a default action):
meta iifname vmap { "foo" : jump foochain, "bar" : accept, default : jump
"rest" }
Would you expect the "packet has no incoming interface" to hit the
default action or not?
If we change things now (set ifindex 0 / "" name), I do not think
we can't revert it later.
