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: <a6fc2d3b3fbd4ed2149fd85a21f7aae8f7fdc926.camel@gmail.com>
Subject: Re: [PATCH] brcmfmac: include missing AP scan feature
From:   James Prestwood <prestwoj@gmail.com>
To:     Alvin =?UTF-8?Q?=C5=A0ipraga?= <ALSI@bang-olufsen.dk>
Cc:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Fri, 25 Feb 2022 15:22:27 -0800
In-Reply-To: <87o82ud09z.fsf@bang-olufsen.dk>
References: <20220224181809.2808754-1-prestwoj@gmail.com>
         <87o82ud09z.fsf@bang-olufsen.dk>
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 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.

Other than this I cant see much else of a use case besides, like you
mentioned, gathering survey data to choose a low load channel (ACS its
called I think?)

Sadly this onboarding use case is quite perfect for DPP, but since
Apple came up with their own protocol DPP won't work for any products
that want cross compatibility...

> 
> Kind regards,
> Alvin
> 
> > 
> > diff --git
> > a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> > index fb727778312c..b6a50e65dbf6 100644
> > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> > @@ -7729,6 +7729,8 @@ struct brcmf_cfg80211_info
> > *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
> >  #endif
> >         }
> >  
> > +       wiphy->features |= NL80211_FEATURE_AP_SCAN;
> > +
> >         return cfg;
> >  
> >  detach: