Re: [PATCH nft 2/2] rule: don't reorder protocol payload expressions when merging

[Florian Westphal <fw@strlen.de>]

Florian Westphal <fw@strlen.de> wrote:
> An instruction like
> 
>  bridge filter input ip saddr 1.2.3.4 ether saddr a:b:c:d:e:f
> 
> is displayed as
> 
> unknown unknown 0x1020304 [invalid type] ether saddr 00:0f:54:0c:11:04 ether type ip
> 
> .. because the (implicit) 'ether type ip' that is injected before the
> network header match gets merged into the ether saddr instruction.
> 
> This inverts the merge in case the merge candidate contains
> a next header protocol field.
> 
> After this change, the rule will be displayed as
> 
> bridge filter input ether saddr a:b:c:d:e:f ip saddr 1.2.3.4

One side-effect with this approach is that it will reorder the
instructions depending on the family dependencies.

So, f.e.
tcp dport 22 ip daddr 1.2.3.4 ether saddr 00:0f:54:0c:11:4

will be added/displayed as
tcp dport 22 ether saddr 00:0f:54:0c:11:04 ip daddr 1.2.3.4

for bridge family, but as

tcp dport 22 ip daddr 1.2.3.4 ether saddr 00:0f:54:0c:11:04

for ip and inet.

In the bridge case we do need a 'is this ip' dependency test, so we
now merge the ether saddr x into the (implicitly inserted)
'ether protocol ip' expression.

ip family doesn't have such a dependency, since network header is
always ipv4.

For INET the dependency is expressed via 'meta load nfproto', so
no payload merge takes place either.

I pushed a rebased version including tests to
https://git.breakpoint.cc/cgit/fw/nftables.git/log/?h=ether_tests_02