Florian Westphal <fw@xxxxxxxxx> 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 -- 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
