On 28 February 2018 at 12:31, Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> wrote: > On 2/27/2018 11:14 AM, Rafał Miłecki wrote: >> >> Sending with a fixed linux-wireless ML address. Please kindly send your >> replies using linux-wireless@ >> >> On 02/27/2018 11:08 AM, Rafał Miłecki wrote: >>> >>> I've problem when using OpenWrt/LEDE on a home router with Broadcom's >>> FullMAC WiFi chipset. >>> >>> >>> First of all OpenWrt/LEDE uses bridge interface for LAN network with: >>> 1) IFLA_BRPORT_MCAST_TO_UCAST >>> 2) Clients isolation in hostapd >>> 3) Hairpin mode enabled >>> >>> For more details please see Linus's patch description: >>> https://patchwork.kernel.org/patch/9530669/ >>> and maybe hairpin mode patch: >>> https://lwn.net/Articles/347344/ >>> >>> Short version: in that setup packets received from a bridged wireless >>> interface can be handled back to it for transmission. >>> >>> >>> Now, Broadcom's firmware for their FullMAC chipsets in AP mode >>> supports an obsoleted 802.11f AKA IAPP standard. It's a roaming >>> standard that was replaced by 802.11r. >>> >>> Whenever a new station associates, firmware generates a packet like: >>> ff ff ff ff ff ff ec 10 7b 5f ?? ?? 00 06 00 01 af 81 01 00 >>> (just masked 2 bytes of my MAC) >>> >>> For mode details you can see discussion in my brcmfmac patch thread: >>> https://patchwork.kernel.org/patch/10191451/ >>> >>> >>> The problem is that bridge (in setup as above) handles such a packet >>> back to the device. > > > From reading the referenced links I understand the hairpin mode is causing > the packet to be sent back to the device, and the hairpin mode is required > for MCAST_TO_UCAST, right? > >>> That makes Broadcom's FullMAC firmware believe that a given station >>> just connected to another AP in a network (which doesn't even exist). >>> As a result firmware immediately disassociates that station. It's >>> simply impossible to connect to the router. Every association is >>> followed by immediate disassociation. >>> >>> >>> Can you see any solution for this problem? Is that an option to stop >>> multicast-to-unicast from touching 802.11f packets? Some other ideas? >>> Obviously I can't modify Broadcom's firmware and drop that obsoleted >>> standard. > > > As far as I can tell you are correct that the 802.11f amendment was never > adopted into the 802.11 standard. I will ask internally if we still have a > reason for carrying it in our firmware. Thanks! Having at least a way to disable it would be nice. That said I think we still should look for a solution for existing firmwares. I guess it may takes months to years to never to release new firmwares for all supported chipsets. -- Rafał
