Re: Adding CMD_SET_CHANNEL for station iftypes

[Arend van Spriel <aspriel@gmail.com>]

On January 8, 2022 12:31:19 AM James Prestwood <prestwoj@gmail.com> wrote:

> On Thu, 2022-01-06 at 23:01 +0100, Johannes Berg wrote:
>> Hi Preston,
>>
>> Ugh, sorry. I'm way behind on a whole bunch of emails (about 4 dozen
>> to
>> be honest) ... trying to catch up, but only so many hours a day.
>
> No worries, thanks for getting to it :)
>
>>

[...]

>
>>
>> At which point it's probably not really worth it? Emulating it in the
>> driver by repeatedly issuing time events also seems like a bad idea,
>> worse even than doing it in the application, since the application
>> could
>> at least try to synchronise it a bit with whatever it needs to be
>> doing,
>> whereas the driver can't do that at all.
>
> If this is the case then sure, its just offloading the same nasty
> procedure into the driver/FW. You know more than me about this topic
> but I'm still trying to understand how this would differ much from AP
> mode?
>
> In my own mind I see SET_CHANNEL doing the same thing as START_AP, just
> without sending out beacons/probes and the iftype being station. Maybe
> this is an oversimplifation but it seems like the FW/driver *can* sit
> on channel without some time constraint if it supports AP mode.

Even if it only supports STA mode it can. The constraint being that it is 
not associated (or busy trying to associate) to an AP. When it is 
associated it has to sit on the channel of the AP, as announced in it's 
beacon and/or probe response, at regular intervals. You referred to DPP to 
provision the STA so I assume it is not associated, right? Could you write 
out the whole scenario as you think it should/could be done?

Regards,
Arend