From: Stephen Hemminger <stephen@networkplumber.org>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Arend van Spriel <arend.vanspriel@broadcom.com>, BROADCOM
Subject: Re: [Bridge] Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
Date: Tue, 27 Feb 2018 09:05:56 -0800 [thread overview]
Message-ID: <20180227090556.02a24a0d@xeon-e3> (raw)
In-Reply-To: <CACna6rz9L09g9oeHhvt209Tg1E3gKgmhGnYF653AdkXfZf=4kw@mail.gmail.com>
On Tue, 27 Feb 2018 11:08:20 +0100
Rafał Miłecki <zajec5@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.
next prev parent reply other threads:[~2018-02-27 17:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 10:08 [Bridge] Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw Rafał Miłecki
2018-02-27 10:14 ` Rafał Miłecki
2018-02-28 11:31 ` Arend van Spriel
2018-03-12 9:49 ` Rafał Miłecki
2018-02-27 17:05 ` Stephen Hemminger [this message]
2018-03-12 9:46 ` Rafał Miłecki
2018-03-12 11:40 ` Linus Lüssing
2018-03-12 11:08 ` Linus Lüssing
2018-03-12 11:48 ` Linus Lüssing
2018-03-12 21:52 ` Rafał Miłecki
2018-03-12 21:49 ` Rafał Miłecki
2018-03-12 22:42 ` Rafał Miłecki
2018-03-12 23:01 ` Stephen Hemminger
2018-03-13 6:23 ` Rafał Miłecki
2018-03-13 7:17 ` Felix Fietkau
2018-03-13 7:20 ` Felix Fietkau
2018-03-13 9:18 ` Arend van Spriel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180227090556.02a24a0d@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=arend.vanspriel@broadcom.com \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox