Re: [RFC ebtables-nft] unify ether type and meta protocol decoding

[Phil Sutter <phil@nwl.cc>]

On Thu, Dec 01, 2022 at 11:16:03AM +0100, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> 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.

Ah, the infamous explicit vs. implicit problem. :(

Looking at ebt_among.c in kernel, it seems packets which are neither
IPv4 nor ARP are treated as non-matching. Since ebtables-nft doesn't
support ARP with among anyway, can we assume people will not specify '-p
ipv4' when using among?

Cheers, Phil