On 28 February 2018 at 12:31, Arend van Spriel
<arend.vanspr...@broadcom.com> 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ł

Reply via email to