Stephen Hemminger
2018-Feb-27 17:05 UTC
[Bridge] Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
On Tue, 27 Feb 2018 11:08:20 +0100 Rafa? Mi?ecki <zajec5 at gmail.com> 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. > > 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. >ebtables is your friend in dealing with weird and broken devices.
Rafał Miłecki
2018-Mar-12 09:46 UTC
[Bridge] Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
On 27 February 2018 at 18:05, Stephen Hemminger <stephen at networkplumber.org> wrote:> On Tue, 27 Feb 2018 11:08:20 +0100 > Rafa? Mi?ecki <zajec5 at gmail.com> 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. >> >> 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. >> > > ebtables is your friend in dealing with weird and broken devices.It may be weird, not sure if actually broken. Anyway I'd like to have some generic solution instead of telling every user to use ebtables to workaround the problem. -- Rafa?
Linus Lüssing
2018-Mar-12 11:40 UTC
[Bridge] Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
On Mon, Mar 12, 2018 at 10:46:45AM +0100, Rafa? Mi?ecki wrote:> On 27 February 2018 at 18:05, Stephen Hemminger[...]> > ebtables is your friend in dealing with weird and broken devices. > > It may be weird, not sure if actually broken. Anyway I'd like to have > some generic solution instead of telling every user to use ebtables to > workaround the problem.I agree that a "broken by default" in OpenWRT/LEDE for a variety of Broadcom devices is not really acceptable. Technically we could teach netifd in OpenWRT/LEDE to configure ebtables accordingly, at least for a list of affected devices, so that users would not have to. However, as ebtables is not managed by the fw3 in OpenWRT/LEDE, that would probably interfer with user provided ebtables rules and scripts...> 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.Hm, we could change the default in OpenWRT/LEDE for multicast-to-unicast (or more precisely bridge hairpinning) to disabled again for now.