Re: [RFC nf-next PATCH] netfilter: nft: introduce broute chain type

[Florian Westphal <fw@strlen.de>]

Sriram Yagnaraman <sriram.yagnaraman@est.tech> wrote:
> Is there any interest or plan to implement BROUTE chain type for nftables?

I'm not aware of anyone working on broute for nftables.
Not sure a new chain type is good, it seems better to implement it via
a new expression.

> We have a situation when a network interface that is part of a bridge is
> used to receive PTP and/or EAPOL packets. Userspace daemons that use
> AF_PACKET to capture specific ether types do not receive the packets,
> and they are instead bridged. We are currently still using etables -t
> broute to send packets packets up the stack. This functionality seems to
> be missing in nftables. Below you can find a proposal that could be used,
> of course there is some work to introduce the chain type and a default
> priority in nftables userspace tool.

Can't you just override the destination mac to point to the bridge
device itself?

> I could see there are other users asking for BROUTE:
> [1]: https://bugzilla.netfilter.org/show_bug.cgi?id=1316
> [2]: https://lore.kernel.org/netfilter-devel/20191024114653.GU25052@breakpoint.cc/
> [3]: https://marc.info/?l=netfilter&m=154807010116514
> 
> broute chain type is just a copy from etables -t broute implementation.
> NF_DROP: skb is routed instead of bridged, and mapped to NF_ACCEPT.
> All other verdicts are returned as it is.
> 
> Please advise if there are better ways to solve this instead of using
> the br_netfilter_broute flag.

The br_netfilter_broute flag is required, but I don't like a new chain
type for this, nor keeping the drop/accept override.

I'd add a new "broute" expression that sets the flag in the skb cb
and sets NF_ACCEPT, useable in bridge family -- I think that this would
be much more readable.

As this expression would be very small I'd make it builtin if nftables
bridge support is enabled.