Phil Sutter <[email protected]> wrote:
> > What it should show instead:
> > Bridge chain: FOOBAR, entries: 1, policy: RETURN
> > -j DROP
> > -d 01:02:03:04:05:06 -j CONTINUE
> >
> > (because thats whats the actual state -- the last rule is unreachable).
>
> Hmm. Yes, that's ugly. Also, if you perform a change to the ruleset in
> that state (no matter what, e.g. just create another chain or add a rule
> somewhere else), the policy rule will be moved to the end. Not sure how
> we could handle this.
I think in that case ebtables-nft should make policy be 'RETURN', i.e.,
not re-add a new policy chain.
I think we could even avoid the 'user comment' and just examine the last
rule in the chain -- check if its unconditional DROP/ACCEPT and then
handle that as the 'policy'.
> > Not a huge deal if we're only interested in "ebtables-nft only".
>
> Maybe that's the only viable option? The only alternative I could think
> of at this point would be to treat the whole chain as incompatible, but
> that's probably not exactly a better way to handle it.
Yes, "incompatible" is worse, I would be fine with 'ebt-nft only'
approach. nft users can either ditch ebtables-nft or use a different
table.
> > @@ -2758,7 +2771,9 @@ static int nft_action(struct nft_handle *h, int
> > action)
> > static int ebt_add_policy_rule(struct nftnl_chain *c, void *data)
> > {
> > uint32_t policy = nftnl_chain_get_u32(c, NFTNL_CHAIN_POLICY);
> > - struct iptables_command_state cs = {};
> > + struct iptables_command_state cs = {
> > + .eb.bitmask = 0x2,
> > + };
> > struct nftnl_udata_buf *udata;
> > struct nft_handle *h = data;
> > struct nftnl_rule *r;
>
> You're not really suggesting to hard-code EBT_NOPROTO value here, right?
No, I was just lazy.
