Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Sep 02, 2025 at 02:08:54PM +0200, Florian Westphal wrote:
> Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> > Expose the input bridge interface ethernet address so it can be used to
> > redirect the packet to the receiving physical device for processing.
> > 
> > Tested with nft command line tool.
> > 
> > table bridge nat {
> > 	chain PREROUTING {
> > 		type filter hook prerouting priority 0; policy accept;
> > 		ether daddr de:ad:00:00:be:ef meta pkttype set host ether daddr set meta ibrhwdr accept
> > 	}
> > }
> > 
> > Joint work with Pablo Neira.
> 
> Sorry for crashing the party.
> 
> Can you check if its enough to use the mac address of the port (rather
> than the bridge address)?
> 
> i.e. add veth0,1 to br0 like this:
> 
>         br0
> a -> [ veth0|veth1 ] -> b
> 
> Then check br0 address.
> If br0 has address of veth1, then try to redirect
> redirect by setting a rule like 'ether daddr set <*veth0 address*>
> 
> AFAICS the bridge FDB should treat this as local, just as if one would
> have used the bridges mac address.

That sounds more generic if it works, yes.

This patch was just mocking the existing behaviour in
net/bridge/netfilter/ebt_redirect.c for this case.

> If it works i think it would be better to place a 'fetch device mac
> address' in nft_meta rather than this ibrhwdr in bridge meta, because
> the former is more generic, even though I don't have a use case other
> than bridge-to-local redirects.
>
> That said, if it doesn't work or the ibrhwdr has another advantage
> I'm missing then I'm fine with this patch.

Unknown to me, but I am fine with reviewing the existing approach and
understand why this bridge redirect was done like this back in 1999.