Received-SPF: pass (google.com: domain of linux-wireless+bounces-3600-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <d8f742a13ad4d299ec23545ee29248989e1b3da5.camel@sipsolutions.net>
Subject: Re: brcmfmac AP mode
From: Johannes Berg <johannes@sipsolutions.net>
To: James Prestwood <prestwoj@gmail.com>, KeithG <ys3al35l@gmail.com>, 
	linux-wireless@vger.kernel.org
Date: Wed, 14 Feb 2024 21:12:19 +0100
In-Reply-To: <4eda39b4-3b16-4f01-a241-50409d34ce33@gmail.com>
References: 
	<CAG17S_MOiC43F2wXMG-Y6nQgitZQJs18jESQJrX+aC6=MQb6ew@mail.gmail.com>
	 <e0825627-4652-4c5a-ae29-33c270a38bc0@gmail.com>
	 <311c594bddde32bacd45acbfa6f40fa7670e51c6.camel@sipsolutions.net>
	 <4eda39b4-3b16-4f01-a241-50409d34ce33@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.3 (3.50.3-1.fc39) 
Precedence: bulk
MIME-Version: 1.0


> > In any case, you could argue that starting AP and client and then
> > scanning is pretty much _asking_ for trouble.
>=20
> Yes I suspected as much. It seems some firmware is just better at this=
=20
> than others.

Sure, that makes sense. Beacons are important, you could schedule (non-
passive) scans between them, and ... yeah you're going to lose frames,
but perhaps not the connection as likely.

> There is one use case there that I believe Kieth is=20
> targeting and that is new device onboarding which I'm sure your familiar=
=20
> with as just about every "smart" device uses it. Where the new devices=
=20
> starts an AP and your phone/App connects and provides credentials to the=
=20
> "real" network.=C2=A0

:)
I always fight with that because typically it wants to transfer the
network credentials from my phone (and be on the same network), but many
devices I don't want to be on the same network ;-)

> The tricky part is having the new device scan for=20
> available networks while it has a client connected. Some drivers support=
=20
> AP scanning which maybe is really what should be used for this? Maybe=20
> that is optimized to actually work.

That really depends how it's implemented, I wouldn't necessarily say
that "AP scanning" is really better. It's still a crutch.

> I guess I'll also ask, what _is_ the target use case for STA + AP=20
> interfaces running concurrently? If scanning is unreliable then=20
> connecting would also be most likely? so what can you actually do here?

You don't _have_ to be scanning on the station all the time if all you
care about is being connected to some other AP? But yeah, it's not all
_that_ useful to have that combination ... and yet I guess people want
it and want to live with the limitations. Especially if firmware is
better than what seems to be the case here.

I dunno. I don't think we support this combination for our devices, but
then again we only really support very limited AP mode.

johannes