From: "Alvin Šipraga" <ALSI@bang-olufsen.dk>
To: James Prestwood <firstname.lastname@example.org>
Cc: "email@example.com" <firstname.lastname@example.org>
Subject: Re: [PATCH] brcmfmac: include missing AP scan feature
Date: Sat, 26 Feb 2022 11:27:47 +0000 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <firstname.lastname@example.org> (James Prestwood's message of "Fri, 25 Feb 2022 15:22:27 -0800")
James Prestwood <email@example.com> writes:
> Hi Alvin,
> On Fri, 2022-02-25 at 22:55 +0000, Alvin Šipraga wrote:
>> Hi James,
>> James Prestwood <firstname.lastname@example.org> 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,
>> that's not a universally applicable assumption. Not all
>> 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
> 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?)
Yes, see hostap/src/ap/acs.c.
for some grumblings of mine on this API.
> 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...
Yes, this is a real shame. And I highly doubt that Apple will abandon
their own protocol.
>> Kind regards,
>> > 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:
next prev parent reply other threads:[~2022-02-26 11:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 18:18 [PATCH] brcmfmac: include missing AP scan feature James Prestwood
2022-02-25 22:55 ` Alvin Šipraga
2022-02-25 23:22 ` James Prestwood
2022-02-26 11:27 ` Alvin Šipraga [this message]
2022-02-28 17:17 ` James Prestwood
2022-03-02 9:24 ` Arend van Spriel
2022-03-02 17:51 ` James Prestwood
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).