Re: Adding CMD_SET_CHANNEL for station iftypes

[James Prestwood <prestwoj@gmail.com>]

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 :)

> 
> > So the use case here is to become provisioned with DPP, or discover
> > another P2P device. For example, you buy a light bulb, plug it in,
> > and
> > want to provision it. Going on channel for small amounts of time
> > can
> > only be detremental to the user experience since you are bound to
> > miss
> > these discovery type frames and delay the provisioning.
> 
> Right.
> 
> > As far as power goes, for at least the above use case, there really
> > isn't an argument. And its a stretch to find a use case of sitting
> > idle
> > as something that anyone wants to do at least for an unprovisioned
> > device that is looking to be configured.
> 
> Fair point.
> 
> > Would there even be a noticable difference in power usage between
> > the
> > two scenarios?
> > 
> >  - Sitting offchannel for 2 minutes
> >  - Issuing REMAIN_ON_CHANNEL repeatedly for 2 minutes
> 
> Probably not :)
> 
> > As far as cancelling CMD_SET_CHANNEL I totally agree. If a device
> > wants
> > to go idle for whatever reason that should definitely be possible.
> > I
> > think a timer could be avoided using SOCKET_OWNER. So if userspace
> > really 'forgets' (crashes or what have you) the device could still
> > be
> > brought to idle if that socket closes.
> 
> Oh, yeah, good point.
> 
> 
> However, looking at something like e.g. iwlwifi, there's no way to
> actually implement what you want, you can't, without a time event
> like
> one created by remain-on-channel, actually just "sit" on a channel.
> 
> So chances are that, even if we implement the API you'd like, it'd
> end
> up being optional and you'd have to support remain-on-channel usage
> like
> before, even for common devices like iwlwifi. (*)

Yes this is inevitable. But this method is really hit or miss honestly.
Each driver arbitrarily chooses its own duration, some as low as 500ms.
My specific iwlwifi card routinely locks up my entire system requring a
hard reboot when I repeatedly issue ROC OR will randomly not send the
ROC event (which I reported on the ML). But I digress.

> 
> 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.

Thanks,
James

> 
> 
> (*) and I'm not even sure we can do anything else from a firmware
> perspective, or at least it'd probably be a complicated fw change
> 
> johannes