Phil Sutter <phil@xxxxxx> wrote: > On Wed, Nov 30, 2022 at 12:37:18PM +0100, Florian Westphal wrote: > > Handle "ether protocol" and "meta protcol" the same. > > > > Problem is that this breaks the test case *again*: > > > > I: [EXECUTING] iptables/tests/shell/testcases/ebtables/0006-flush_0 > > --A FORWARD --among-dst fe:ed:ba:be:13:37=10.0.0.1 -j ACCEPT > > --A OUTPUT --among-src c0:ff:ee:90:0:0=192.168.0.1 -j DROP > > +-A FORWARD -p IPv4 --among-dst fe:ed:ba:be:13:37=10.0.0.1 -j ACCEPT > > +-A OUTPUT -p IPv4 --among-src c0:ff:ee:90:0:0=192.168.0.1 -j DROP > > > > ... because ebtables-nft will now render meta protocol as "-p IPv4". > > > > ebtables-legacy does not have any special handling for this. > > > > Solving this would need more internal annotations during decode, so > > we can suppress/ignore "meta protocol" once a "among-type" set is > > encountered. > > > > Any (other) suggestions? > > Since ebtables among does not support IPv6, match elimination should be > pretty simple, no? Entirely untested: > > diff --git a/iptables/nft-bridge.c b/iptables/nft-bridge.c > index 08c93feeba2c9..0daebfd983127 100644 > --- a/iptables/nft-bridge.c > +++ b/iptables/nft-bridge.c > @@ -520,6 +520,10 @@ static void nft_bridge_parse_lookup(struct nft_xt_ctx *ctx, > if (set_elems_to_among_pairs(among_data->pairs + poff, s, cnt)) > xtables_error(OTHER_PROBLEM, > "ebtables among pair parsing failed"); > + > + if (!(ctx->cs.eb.bitmask & EBT_NOPROTO) && > + ctx->cs.eb.ethproto == htons(0x0800)) > + ctx->cs.eb.bitmask |= EBT_NOPROTO; But that would munge ebtables-nft -p ipv4 .... ebtables-nft .... We don't know if "-p" was added explicitly or not.
