Semantics of AF_PACKET sockets on bridge port interface

Semantics of AF_PACKET sockets on bridge port interface

[Russell King - ARM Linux admin]

Hi,

This question has probably come up several times before, but there
doesn't seem to be a solution yet.

Scenario: a network interface, such as a wireless adapter or a
network interface supporting PTP, is part of a bridge. Userspace
wishes to capture packets sent using a specific Ethernet protocol
to the ethernet address of that network interface, such as EAPOL
frames or PTP frames.

Problem 1: __netif_receive_skb_core() scans the global ptype_all and
skb->dev->ptype_all lists to deliver to any packet capture sockets,
then checks skb->dev->rx_handler (which bridge sets), and from which
it returns RX_HANDLER_CONSUMED from. This bypasses AF_PACKET listeners
attached via the ->ptype_specific list, resulting in such a socket
not receiving any packets.

Problem 2: detecting the port being a bridge port, and having the
application also bind to the bridge interface is not a solution; the
bridge can have a different MAC address to the bridge interface, so
e.g. EAPOL frames sent to the WiFi MAC address will not be routed to
the bridge interface. (hostapd does this but it's fragile for this
reason, and it doesn't work for ptp nor does it work for Network
Manager based bridged Wi-Fi which uses wpa_supplicant.)

So, this problem really does need solving, but it doesn't look to be
trivial.  Moving the scanning of the device's ptype_specific list
has implications for ingress and vlan handling.

I'm aware of a large patch set in 2019 that contained a single patch
that claimed to fix it, but it looks like it was ignored, which is
not surprising given the size and content of the series.
https://lore.kernel.org/patchwork/patch/1066146/
This patch no longer applies to current kernels since the bridge code
has changed, and in any case, I suspect the fix is wrong.

Is there a solution for this, or are AF_PACKET ethernet-protocol
specific sockets just not supportable on bridge ports?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: Semantics of AF_PACKET sockets on bridge port interface

[Russell King - ARM Linux admin]

On Sat, Apr 03, 2021 at 10:54:18AM +0100, Russell King - ARM Linux admin wrote:
> Hi,
> 
> This question has probably come up several times before, but there
> doesn't seem to be a solution yet.
> 
> Scenario: a network interface, such as a wireless adapter or a
> network interface supporting PTP, is part of a bridge. Userspace
> wishes to capture packets sent using a specific Ethernet protocol
> to the ethernet address of that network interface, such as EAPOL
> frames or PTP frames.
> 
> Problem 1: __netif_receive_skb_core() scans the global ptype_all and
> skb->dev->ptype_all lists to deliver to any packet capture sockets,
> then checks skb->dev->rx_handler (which bridge sets), and from which
> it returns RX_HANDLER_CONSUMED from. This bypasses AF_PACKET listeners
> attached via the ->ptype_specific list, resulting in such a socket
> not receiving any packets.
> 
> Problem 2: detecting the port being a bridge port, and having the
> application also bind to the bridge interface is not a solution; the
> bridge can have a different MAC address to the bridge interface, so
> e.g. EAPOL frames sent to the WiFi MAC address will not be routed to
> the bridge interface. (hostapd does this but it's fragile for this
> reason, and it doesn't work for ptp nor does it work for Network
> Manager based bridged Wi-Fi which uses wpa_supplicant.)
> 
> So, this problem really does need solving, but it doesn't look to be
> trivial.  Moving the scanning of the device's ptype_specific list
> has implications for ingress and vlan handling.
> 
> I'm aware of a large patch set in 2019 that contained a single patch
> that claimed to fix it, but it looks like it was ignored, which is
> not surprising given the size and content of the series.
> https://lore.kernel.org/patchwork/patch/1066146/
> This patch no longer applies to current kernels since the bridge code
> has changed, and in any case, I suspect the fix is wrong.
> 
> Is there a solution for this, or are AF_PACKET ethernet-protocol
> specific sockets just not supportable on bridge ports?

Would having the bridge code return RX_HANDLER_EXACT rather than
RX_HANDLER_CONSUMED would solve this problem with minimal side effects?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: Semantics of AF_PACKET sockets on bridge port interface - patch

[Russell King - ARM Linux admin]

On Sat, Apr 03, 2021 at 10:54:18AM +0100, Russell King - ARM Linux admin wrote:
> Hi,
> 
> This question has probably come up several times before, but there
> doesn't seem to be a solution yet.
> 
> Scenario: a network interface, such as a wireless adapter or a
> network interface supporting PTP, is part of a bridge. Userspace
> wishes to capture packets sent using a specific Ethernet protocol
> to the ethernet address of that network interface, such as EAPOL
> frames or PTP frames.
> 
> Problem 1: __netif_receive_skb_core() scans the global ptype_all and
> skb->dev->ptype_all lists to deliver to any packet capture sockets,
> then checks skb->dev->rx_handler (which bridge sets), and from which
> it returns RX_HANDLER_CONSUMED from. This bypasses AF_PACKET listeners
> attached via the ->ptype_specific list, resulting in such a socket
> not receiving any packets.
> 
> Problem 2: detecting the port being a bridge port, and having the
> application also bind to the bridge interface is not a solution; the
> bridge can have a different MAC address to the bridge interface, so
> e.g. EAPOL frames sent to the WiFi MAC address will not be routed to
> the bridge interface. (hostapd does this but it's fragile for this
> reason, and it doesn't work for ptp nor does it work for Network
> Manager based bridged Wi-Fi which uses wpa_supplicant.)
> 
> So, this problem really does need solving, but it doesn't look to be
> trivial.  Moving the scanning of the device's ptype_specific list
> has implications for ingress and vlan handling.
> 
> I'm aware of a large patch set in 2019 that contained a single patch
> that claimed to fix it, but it looks like it was ignored, which is
> not surprising given the size and content of the series.
> https://lore.kernel.org/patchwork/patch/1066146/
> This patch no longer applies to current kernels since the bridge code
> has changed, and in any case, I suspect the fix is wrong.
> 
> Is there a solution for this, or are AF_PACKET ethernet-protocol
> specific sockets just not supportable on bridge ports?

The patch below is a hack I've tried to fix this problem, and with this
I can configure a Wi-Fi AP in Network Manager beneath a bridge, and
have it accept clients onto the network. Without this patch, they fail
while trying to complete the EAPOL authentication. This setup uses
wpa_supplicant attached to the Wi-Fi interface which has no knowledge
that the interface is attached to a bridge.

diff --git a/net/core/dev.c b/net/core/dev.c
index 449b45b843d4..41f9ce764654 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5208,6 +5208,10 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc,
 			goto out;
 	}
 
+	type = skb->protocol;
+	deliver_ptype_list_skb(skb, &pt_prev, orig_dev, type,
+			       &orig_dev->ptype_specific);
+
 	rx_handler = rcu_dereference(skb->dev->rx_handler);
 	if (rx_handler) {
 		if (pt_prev) {
@@ -5276,9 +5280,6 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc,
 						   PTYPE_HASH_MASK]);
 	}
 
-	deliver_ptype_list_skb(skb, &pt_prev, orig_dev, type,
-			       &orig_dev->ptype_specific);
-
 	if (unlikely(skb->dev != orig_dev)) {
 		deliver_ptype_list_skb(skb, &pt_prev, orig_dev, type,
 				       &skb->dev->ptype_specific);

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!