From: Eric Woudstra <ericwouds@gmail.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>,
Jozsef Kadlecsik <kadlec@netfilter.org>,
Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,
Nikolay Aleksandrov <razor@blackwall.org>,
Ido Schimmel <idosch@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>
Cc: netfilter-devel@vger.kernel.org, bridge@lists.linux.dev,
netdev@vger.kernel.org, Eric Woudstra <ericwouds@gmail.com>
Subject: [PATCH v16 nf-next 3/3] netfilter: nft_chain_filter: Add bridge double vlan and pppoe
Date: Tue, 4 Nov 2025 15:57:28 +0100 [thread overview]
Message-ID: <20251104145728.517197-4-ericwouds@gmail.com> (raw)
In-Reply-To: <20251104145728.517197-1-ericwouds@gmail.com>
In nft_do_chain_bridge() pktinfo is only fully populated for plain packets
and packets encapsulated in single 802.1q or 802.1ad.
When implementing the software bridge-fastpath and testing all possible
encapulations, there can be more encapsulations:
The packet could (also) be encapsulated in PPPoE, or the packet could be
encapsulated in an inner 802.1q, combined with an outer 802.1ad or 802.1q
encapsulation.
nft_flow_offload_eval() also examines the L4 header, with the L4 protocol
known from the conntrack-tuplehash. To access the header it uses
nft_thoff(), but for these packets it returns zero.
Introduce nft_set_bridge_pktinfo() to help populate pktinfo with the
offsets, without setting pkt->tprot and the corresponding pkt->flags.
This will not change rule processing, but does make these offsets
available for code that is not checking pkt->flags to use the offsets,
like nft_flow_offload_eval().
Existing behaviour for a rule like "tcp dport 22 accept" is not changed
when, for instance, a PPPoE packet is being matched.
Signed-off-by: Eric Woudstra <ericwouds@gmail.com>
---
net/netfilter/nft_chain_filter.c | 58 ++++++++++++++++++++++++++++++--
1 file changed, 56 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nft_chain_filter.c b/net/netfilter/nft_chain_filter.c
index b16185e9a6dd..1f3ae5687917 100644
--- a/net/netfilter/nft_chain_filter.c
+++ b/net/netfilter/nft_chain_filter.c
@@ -227,16 +227,64 @@ static inline void nft_chain_filter_inet_fini(void) {}
#endif /* CONFIG_NF_TABLES_IPV6 */
#if IS_ENABLED(CONFIG_NF_TABLES_BRIDGE)
+static int nft_set_bridge_pktinfo(struct nft_pktinfo *pkt, struct sk_buff *skb,
+ const struct nf_hook_state *state,
+ __be16 *proto)
+{
+ nft_set_pktinfo(pkt, skb, state);
+
+ switch (*proto) {
+ case htons(ETH_P_PPP_SES): {
+ struct ppp_hdr {
+ struct pppoe_hdr hdr;
+ __be16 proto;
+ } *ph;
+
+ if (!pskb_may_pull(skb, PPPOE_SES_HLEN))
+ return -1;
+ ph = (struct ppp_hdr *)(skb->data);
+ switch (ph->proto) {
+ case htons(PPP_IP):
+ *proto = htons(ETH_P_IP);
+ skb_set_network_header(skb, PPPOE_SES_HLEN);
+ return PPPOE_SES_HLEN;
+ case htons(PPP_IPV6):
+ *proto = htons(ETH_P_IPV6);
+ skb_set_network_header(skb, PPPOE_SES_HLEN);
+ return PPPOE_SES_HLEN;
+ }
+ break;
+ }
+ case htons(ETH_P_8021Q): {
+ struct vlan_hdr *vhdr;
+
+ if (!pskb_may_pull(skb, VLAN_HLEN))
+ return -1;
+ vhdr = (struct vlan_hdr *)(skb->data);
+ *proto = vhdr->h_vlan_encapsulated_proto;
+ skb_set_network_header(skb, VLAN_HLEN);
+ return VLAN_HLEN;
+ }
+ }
+ return 0;
+}
+
static unsigned int
nft_do_chain_bridge(void *priv,
struct sk_buff *skb,
const struct nf_hook_state *state)
{
struct nft_pktinfo pkt;
+ __be16 proto;
+ int offset;
- nft_set_pktinfo(&pkt, skb, state);
+ proto = eth_hdr(skb)->h_proto;
- switch (eth_hdr(skb)->h_proto) {
+ offset = nft_set_bridge_pktinfo(&pkt, skb, state, &proto);
+ if (offset < 0)
+ return NF_ACCEPT;
+
+ switch (proto) {
case htons(ETH_P_IP):
nft_set_pktinfo_ipv4_validate(&pkt);
break;
@@ -248,6 +296,12 @@ nft_do_chain_bridge(void *priv,
break;
}
+ if (offset) {
+ skb_reset_network_header(skb);
+ pkt.flags = 0;
+ pkt.tprot = 0;
+ }
+
return nft_do_chain(&pkt, priv);
}
--
2.50.0
next prev parent reply other threads:[~2025-11-04 14:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 14:57 [PATCH v16 nf-next 0/3] conntrack: bridge: add double vlan, pppoe and pppoe-in-q Eric Woudstra
2025-11-04 14:57 ` [PATCH v16 nf-next 1/3] netfilter: utils: nf_checksum(_partial) correct data!=networkheader Eric Woudstra
2025-11-04 14:57 ` [PATCH v16 nf-next 2/3] netfilter: bridge: Add conntrack double vlan and pppoe Eric Woudstra
2025-11-04 14:57 ` Eric Woudstra [this message]
2025-11-04 15:53 ` [PATCH v16 nf-next 3/3] netfilter: nft_chain_filter: Add bridge " Florian Westphal
2025-11-04 19:15 ` Eric Woudstra
2025-11-06 23:47 ` Florian Westphal
2025-11-07 0:06 ` 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=20251104145728.517197-4-ericwouds@gmail.com \
--to=ericwouds@gmail.com \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
--cc=razor@blackwall.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