netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Fernando Fernandez Mancera <fmancera@suse.de>
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
	pablo@netfilter.org
Subject: Re: [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support
Date: Tue, 2 Sep 2025 14:08:54 +0200	[thread overview]
Message-ID: <aLbeVpmjrPCPUiYH@strlen.de> (raw)
In-Reply-To: <20250902112808.5139-1-fmancera@suse.de>

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.

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.

  reply	other threads:[~2025-09-02 12:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-02 11:28 [PATCH nf-next] netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support Fernando Fernandez Mancera
2025-09-02 12:08 ` Florian Westphal [this message]
2025-09-02 14:37   ` Pablo Neira Ayuso
2025-09-02 15:34     ` Fernando Fernandez Mancera
2025-09-02 15:58       ` Pablo Neira Ayuso
2025-09-02 16:05         ` Fernando Fernandez Mancera
2025-09-02 16:33         ` Florian Westphal
2025-09-02 17:02           ` Fernando Fernandez Mancera
2025-09-02 17:07             ` Florian Westphal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aLbeVpmjrPCPUiYH@strlen.de \
    --to=fw@strlen.de \
    --cc=coreteam@netfilter.org \
    --cc=fmancera@suse.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).