> -----Original Message----- > From: Florian Westphal <fw@xxxxxxxxx> > Sent: Wednesday, 22 February 2023 12:38 > To: Sriram Yagnaraman <sriram.yagnaraman@xxxxxxxx> > Cc: netfilter-devel@xxxxxxxxxxxxxxx; Florian Westphal <fw@xxxxxxxxx>; Pablo > Neira Ayuso <pablo@xxxxxxxxxxxxx> > Subject: Re: [RFC nf-next PATCH] netfilter: nft: introduce broute chain type > > 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? Yes, but then we will have to run the user space daemon on the bridge instead. My stakeholders want to continue running on the bridge port/slave the packets are received on, and hence this request to support BROUTE. > > > 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@breakpo > > int.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.
