On Tue, Sep 02, 2025 at 02:08:54PM +0200, Florian Westphal wrote:
> Fernando Fernandez Mancera <fmancera@xxxxxxx> 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.
