Sriram Yagnaraman <sriram.yagnaraman@xxxxxxxx> 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@xxxxxxxxxxxxx/ > [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.
