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!
