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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> -----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]:
> > [2]:
> >
> devel/20191024114653.GU25052@breakpo
> >
> > [3]:
> >
> > 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.

[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux