From patchwork Mon Mar 12 22:42:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= X-Patchwork-Id: 10277623 X-Patchwork-Delegate: kvalo@adurom.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 80A3F602BD for ; Mon, 12 Mar 2018 22:42:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 703C8286F2 for ; Mon, 12 Mar 2018 22:42:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 643F128823; Mon, 12 Mar 2018 22:42:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A4B3B286F2 for ; Mon, 12 Mar 2018 22:42:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932225AbeCLWm5 (ORCPT ); Mon, 12 Mar 2018 18:42:57 -0400 Received: from mail-lf0-f41.google.com ([209.85.215.41]:44127 "EHLO mail-lf0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751520AbeCLWmy (ORCPT ); Mon, 12 Mar 2018 18:42:54 -0400 Received: by mail-lf0-f41.google.com with SMTP id v9-v6so25753816lfa.11; Mon, 12 Mar 2018 15:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=iTod4GqM7oRLZbyuCdudDKz0BUKWYYGK5Kbepvso5Ms=; b=Zk7k1CMVMMkeaP/lYKHt7ePz7A+gi0rqmsJ8C4rS87a1sN/balcJWRP63zR7bYBYF4 ZI8MCGGEoE6E5ONWAyZajf1ZFBvLcvd6fx7nEavogo5dpWBP9YX9UZA3/OAk428Jec4n gaZq1uFrrCEoAIKcnIVAzehuxtTdbGkxOyX/O6ESEKttcfFGLhA+SaXaAtuyxuJCH/ZU uYDX7XSKtmhOT5w28wvNKMPsL6OFz1mR9lefQgbrRd8gbnkd6EJG+IQuUeTtAj/BIztR CM1xKBkYuVhimqba2sPvoABv+jgbFLINuL6HvC3gUfjwW60xug9nHTvKGOBbm6C0DFmZ np9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=iTod4GqM7oRLZbyuCdudDKz0BUKWYYGK5Kbepvso5Ms=; b=I9fyWy0rM2a4dXTOnUM4HFtme3O4UfZrDeOJNMbIEQRvJ7diMT0mWzDlWS/PH4ZMGQ ALHxHUKARgsWZ058K45JXkxM70n3Br7G6FoKiLIokDgw08+pVmxhHM1n3mOU8rE9lg95 N78/XmPjDFl83dER07S6B/16o84YzOdoHHMOdShFPFFsJse7g/UYntOmlQGQXBBO0T1C 3OgDj9hSLJM+bRWZuceEkbiqV8AjTliycpkOOXNJjQlVCSxL7ds6yqAdKaB3pHC68eYZ 2S/88/i0C+xeAXUp+fKXkhLCLCSfjubThocD5412uOx3DfMBKAF0yIKQJ2yDFrn4dCpD P2XQ== X-Gm-Message-State: AElRT7FnHi8Q7sFV1uUmJ0Pg2yBJ8fw3r3l4eKLpnjFWa7MzB3lLBR9Y j47er1Kh/w6QvJ2W6t3V9GjGgQ== X-Google-Smtp-Source: AG47ELuHVEeo1K8X7j5fay8l1WUApHTHLZctHo8XFHMndklX9TmcUDUQbYZOz4441EPvXGQ0N3rljA== X-Received: by 2002:a19:1754:: with SMTP id n81-v6mr4106719lfi.113.1520894572084; Mon, 12 Mar 2018 15:42:52 -0700 (PDT) Received: from linux-samsung.lan (ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233]) by smtp.googlemail.com with ESMTPSA id u65sm1974343lje.79.2018.03.12.15.42.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 15:42:50 -0700 (PDT) Subject: Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw To: =?UTF-8?Q?Linus_L=c3=bcssing?= , Felix Fietkau , Arend van Spriel , Franky Lin , Hante Meuleman , Chi-Hsien Lin , Wright Feng , Pieter-Paul Giesberts References: Cc: Network Development , bridge@lists.linux-foundation.org, linux-wireless@vger.kernel.org, "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" , brcm80211-dev-list@cypress.com From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= Message-ID: Date: Mon, 12 Mar 2018 23:42:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. > > 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. I kept thinking about this for a bit more. We probably have to start with deciding what to blame for this problem. I see two options I'll describe below. Please share your opinions on this. 1) Blame brcmfmac fw for implementing 802.11f In that case we should add workaround to brcmfmac driver to drop/ignore 802.11f packets. A slightly improved version of my [PATCH] brcmfmac: detect & reject faked packet generated by a firmware https://patchwork.kernel.org/patch/10191451/ should work. 2) Blame bridge + mcast-to-ucast + hairpin for 802.11f incompatibility If we agree that 802.11f support in FullMAC firmware is acceptable, then we have to make sure Linux's bridge doesn't break it by passing 802.11f (broadcast) frames back to the source interface. That would require a check like in below diff + proper code for handling such packets. I'm afraid I'm not familiar with bridge code enough to complete that. diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c index edae702..9e5d6ea 100644 --- a/net/bridge/br_input.c +++ b/net/bridge/br_input.c @@ -126,6 +126,27 @@ static void br_do_proxy_arp(struct sk_buff *skb, struct net_bridge *br, } } +static bool br_skb_is_iapp_add_packet(struct sk_buff *skb) +{ + const u8 iapp_add_packet[6] __aligned(2) = { + 0x00, 0x01, 0xaf, 0x81, 0x01, 0x00, + }; +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) + const u16 *a = (const u16 *)skb->data; + const u16 *b = (const u16 *)iapp_add_packet; +#endif + + if (skb->len != 6) + return false; + +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) + return !(((*(const u32 *)skb->data) ^ (*(const u32 *)iapp_add_packet)) | + ((*(const u16 *)(skb->data + 4)) ^ (*(const u16 *)(iapp_add_packet + 4)))); +#else + return !((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])); +#endif +} + /* note: already called with rcu_read_lock */ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb) { @@ -155,6 +176,8 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb if (is_multicast_ether_addr(dest)) { /* by definition the broadcast is also a multicast address */ if (is_broadcast_ether_addr(dest)) { + if (br_skb_is_iapp_add_packet(skb)) + pr_warn("This packet should not be passed back to the source interface!\n"); pkt_type = BR_PKT_BROADCAST; local_rcv = true; } else {