lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 28 Feb 2018 12:31:31 +0100 From: Arend van Spriel <arend.vanspriel@...adcom.com> To: Rafał Miłecki <zajec5@...il.com>, Linus Lüssing <linus.luessing@...3.blue>, Felix Fietkau <nbd@....name>, Franky Lin <franky.lin@...adcom.com>, Hante Meuleman <hante.meuleman@...adcom.com>, Chi-Hsien Lin <chi-hsien.lin@...ress.com>, Wright Feng <wright.feng@...ress.com>, Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com> Cc: Network Development <netdev@...r.kernel.org>, bridge@...ts.linux-foundation.org, "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>, "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" <brcm80211-dev-list.pdl@...adcom.com>, brcm80211-dev-list@...ress.com Subject: Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw 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. Regards, Arend
Powered by blists - more mailing lists