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

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


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]:
> [2]:
> [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