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!
