Received-SPF: pass (google.com: domain of linux-wireless+bounces-3599-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <4eda39b4-3b16-4f01-a241-50409d34ce33@gmail.com>
Date: Wed, 14 Feb 2024 11:31:07 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: brcmfmac AP mode
Content-Language: en-US
To: Johannes Berg <johannes@sipsolutions.net>, KeithG <ys3al35l@gmail.com>,
 linux-wireless@vger.kernel.org
References: <CAG17S_MOiC43F2wXMG-Y6nQgitZQJs18jESQJrX+aC6=MQb6ew@mail.gmail.com>
 <e0825627-4652-4c5a-ae29-33c270a38bc0@gmail.com>
 <311c594bddde32bacd45acbfa6f40fa7670e51c6.camel@sipsolutions.net>
From: James Prestwood <prestwoj@gmail.com>
In-Reply-To: <311c594bddde32bacd45acbfa6f40fa7670e51c6.camel@sipsolutions.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Johannes,

On 2/14/24 6:34 AM, Johannes Berg wrote:
> I have no experience with brcmfmac, but ...
>
>> I was helping Keith out here and wanted to provide a bit more
>> information. I found there were a few differences between IWD and
>> wpa_supplicant related to scanning which may aid in figuring out why
>> brcmfmac is behaving this way:
>>
>>    - IWD scans using the wdev ID where wpa_supplicant uses ifindex. Not
>> sure if this has anything to do with the difference behavior.
> This is not even visible to the driver, it's entirely resolved in
> nl80211, so no impact here.
>
>>    - Passive scans (which IWD prefers) seem to exacerbate the behavior.
>> Simple testing using "wpa_cli scan" showed wpa_supplicant was only using
>> active scans. I also tested with iw and saw repeatable disconnects when
>> passive scanning. Disconnects while using active scans (using iw) were
>> much less frequent.
> This makes sense, especially if it's __ap rather than __p2p_go type,
> since it *has* to be off the channel for some time -- especially for
> passive scans it has to be off-channel for more than a typical interval
> to even do scanning correctly.
>
>>    - Scanning with IWD, wpa_supplicant, or iw, passive or active, always
>> resulted in beacon loss for clients connected to the AP. This was 100%
>> guaranteed. The clients just could recover when active scans were used
>> over passive. But either way this does not seem like normal behavior,
>> the AP interface should still be beaconing on its active channel during
>> a scan right?
> That's "normal" in the sense that you have to be off the channel for
> scanning, and if you're off the channel you can't transmit beacons on
> it?
>
> For P2P GO rather than AP it should publish NoA descriptors in the
> beacon to let clients know there won't be a beacon.
>
> Now it's perhaps possible to time - especially active - scanning so you
> can still beacon somewhat and inbetween, but I suppose the firmware
> doesn't do that here.
>
> In fact even outside of the beaconing, APs aren't expected to be off-
> channel, clients can send data to them after all. Again P2P GO solves
> that with NoA, but the spec itself has no good way to solve this and I'm
> not even sure it would even want to.
>
> In any case, you could argue that starting AP and client and then
> scanning is pretty much _asking_ for trouble.

Yes I suspected as much. It seems some firmware is just better at this 
than others. There is one use case there that I believe Kieth is 
targeting and that is new device onboarding which I'm sure your familiar 
with as just about every "smart" device uses it. Where the new devices 
starts an AP and your phone/App connects and provides credentials to the 
"real" network. The tricky part is having the new device scan for 
available networks while it has a client connected. Some drivers support 
AP scanning which maybe is really what should be used for this? Maybe 
that is optimized to actually work.

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

>> If this isn't possible or can't be done reliably then
>> should the interface combinations be changed to disallow concurrent sta
>> + AP mode interfaces?
> Maybe it could restrict it to P2P GO instead of AP? But then people will
> anyway just notice that they can use P2P GO and connect arbitrary
> clients to it (not just P2P client), then those clients won't honour the
> NoA because they're not P2P, and then you're back to the exact same
> situation...
> johannes