Skip to contentSkip to conversation

Semantics of AF_PACKET sockets on bridge port interface

DISCUSSION Russell King - ARM Linux admin 1 participant 3 messages Apr 3, 2021 – Apr 7, 2021

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Russell King - ARM Linux admin

author
#0 lore raw

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.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
author
#1 lore raw
Quoted 37 lines · 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.

Quoted 2 lines

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.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
author
#2 lore raw

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

In reply to Russell King - ARM Linux admin
Quoted 37 lines · 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.

Quoted 2 lines

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.

net/core/dev.c +4 -3
index 449b45b843d4..41f9ce764654 100644
@@ -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);
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!