Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <d4cce352c09145afa95870532c27ebe9eef56328.camel@gmail.com>
Subject: Re: [PATCH] brcmfmac: include missing AP scan feature
From:   James Prestwood <prestwoj@gmail.com>
To:     Arend van Spriel <arend.vanspriel@broadcom.com>,
        Alvin =?UTF-8?Q?=C5=A0ipraga?= <ALSI@bang-olufsen.dk>
Cc:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Wed, 02 Mar 2022 09:51:58 -0800
In-Reply-To: <89b87db4-1751-21b2-3e22-94d71e46c8d2@broadcom.com>
References: <20220224181809.2808754-1-prestwoj@gmail.com>
         <87o82ud09z.fsf@bang-olufsen.dk>
         <a6fc2d3b3fbd4ed2149fd85a21f7aae8f7fdc926.camel@gmail.com>
         <87k0dhdg0d.fsf@bang-olufsen.dk>
         <50df7d732efb392a6669d89e0893b17f8cec4204.camel@gmail.com>
         <89b87db4-1751-21b2-3e22-94d71e46c8d2@broadcom.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Arend,

On Wed, 2022-03-02 at 10:24 +0100, Arend van Spriel wrote:
> On 2/28/2022 6:17 PM, James Prestwood wrote:
> > Hi Alvin,
> > 
> > On Sat, 2022-02-26 at 11:27 +0000, Alvin Šipraga wrote:
> > > Hi James,
> > > 
> > > James Prestwood <prestwoj@gmail.com> writes:
> > > 
> > > > Hi Alvin,
> > > > 
> > > > On Fri, 2022-02-25 at 22:55 +0000, Alvin Šipraga wrote:
> > > > > Hi James,
> > > > > 
> > > > > James Prestwood <prestwoj@gmail.com> writes:
> > > > > 
> > > > > > This driver does not advertise this feature yet scanning
> > > > > > with
> > > > > > on an
> > > > > > AP interface appears to work just fine.
> > > > > > ---
> > > > > >   drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211
> > > > > > .c |
> > > > > > 2 ++
> > > > > >   1 file changed, 2 insertions(+)
> > > > > > 
> > > > > > I've submitted this patch mainly to start a discussion
> > > > > > about
> > > > > > it. I
> > > > > > find it hard to believe that ALL brcmfmac devices support
> > > > > > AP
> > > > > > scanning
> > > > > > in which case this feature needs to be limited to those
> > > > > > devices
> > > > > > only. Trouble is there is no FW feature for AP scanning
> > > > > > AFAIK.
> > > > > > 
> > > > > > In any case I think this driver needs to sort out if it
> > > > > > supports
> > > > > > this
> > > > > > feature or not, and advertise as such rather than leaving
> > > > > > userspace
> > > > > > in the dark.
> > > > > 
> > > > > By the way, what are the typical use-cases for AP scanning?
> > > > > 
> > > > > I know that hostapd does a passive scan on the AP interface
> > > > > on
> > > > > the
> > > > > assumption that the driver/firmware will gather channel
> > > > > survey
> > > > > data,
> > > > > but
> > > > > that's not a universally applicable assumption. Not all
> > > > > implementations
> > > > > will do that.
> > > > 
> > > > We have someone wanting it for onboarding/configuring a new
> > > > headless
> > > > device. Where on boot, if it is unconfigured, it starts an AP
> > > > and
> > > > waits
> > > > for a client to configure it.
> > > > 
> > > > A client would connect, have the device scan and present
> > > > available
> > > > networks. The client then selects a network and provides
> > > > credentials.
> > > > The new device can then switch back to station mode and
> > > > connect.
> > > > 
> > > > This is a relatively common practice I've seen with IoT
> > > > devices.
> > > 
> > > Ah OK! Actually we do pretty much the same here at B&O with
> > > brcmfmac. But rather than starting the AP on the primary
> > > interface
> > > (the
> > > one default created by the driver), we add a separate AP
> > > interface
> > > with
> > > the equivalent of the following command:
> > > 
> > > # iw dev wlan0 add uap0 type __ap
> > > 
> > > Here wlan0 is the primary interface, and uap0 is what I call my
> > > AP.
> > > 
> > > In that case you can start the AP on uap0, but still do scanning
> > > on
> > > wlan0 (which remains in station mode). Don't quote me on it, but
> > > I
> > > think
> > > this is the canonical approach with this driver. Is it something
> > > you
> > > have considered?
> > 
> > Thanks, this does seem to work on brcmfmac. I had tried this on
> > other
> > hardware without any luck. I mentioned this to the user but since
> > the
> > AP scanning feature has been implemented they may want to still use
> > that, but who knows. I think finding out if brcmfmac is intended to
> > scan on the AP interface would still be good to know.
> 
> There is no easy answer to that. It really depends on the 
> device/firmware. To be honest I don't know if the older chips can 
> support it. Need to check that.

Thats what I figured.

> 
> What device are you specifically looking at?

I've tried on a Raspberry Pi 3, which is a BCM4345 I believe.

But I'm not too concerned about knowing for this one device. We really
would like a general way to know, i.e. the feature flag. If this is
possible to set based on some FW values that would be great to do.
Otherwise, if its not possible, saying "No it doesn't support it" is
also fine with me, and we can continue on assuming brcmfmac as a whole
doesn't support it.

What is confusing (to me) is the lack of the feature flag but the
driver still accepts scans on AP interfaces, as well as accepting the
NL80211_SCAN_FLAG_AP. I would expect CMD_TRIGGER scan to fail with "Not
Supported".

Thanks,
James

> 
> Regards,
> Arend