On January 8, 2022 12:31:19 AM James Prestwood <prestwoj@xxxxxxxxx> 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
