Adding CMD_SET_CHANNEL for station iftypes

Adding CMD_SET_CHANNEL for station iftypes

[James Prestwood]

Hi,

I see CMD_SET_CHANNEL is only supported for AP-type iftypes (AP,
P2P_GO, etc). While this definitely makes sense in most cases,
protocols like p2p/dpp require going off channel for an undetermined
amount of time.

I could go into the exact scenarios but in short your REMAIN_ON_CHANNEL
could end at very inconvenient times.

Specifically when a station is not associated to any AP is there any
harm in allowing CMD_SET_CHANNEL? Is this purely a software limitation
or do drivers not allow this?

If this sounds reasonable (and possible) I would propose adding the
station iftype to CMD_SET_CHANNEL in addition to an extended feature
e.g. NL80211_EXT_FEATURE_STA_SET_CHANNEL so supplicants can detect
support or fall back to using REMAIN_ON_CHANNEL for these specific use
cases.

Thanks,
James

Re: Adding CMD_SET_CHANNEL for station iftypes

[Johannes Berg]

On Thu, 2021-11-18 at 16:11 -0800, James Prestwood wrote:
> Hi,
> 
> I see CMD_SET_CHANNEL is only supported for AP-type iftypes (AP,
> P2P_GO, etc). While this definitely makes sense in most cases,
> protocols like p2p/dpp require going off channel for an undetermined
> amount of time.
> 
> I could go into the exact scenarios but in short your REMAIN_ON_CHANNEL
> could end at very inconvenient times.
> 
> Specifically when a station is not associated to any AP is there any
> harm in allowing CMD_SET_CHANNEL? Is this purely a software limitation
> or do drivers not allow this?
> 
> If this sounds reasonable (and possible)

I don't think this *works* because you don't have a way to say "I want
to now go back to idle". And sitting on a channel arbitrarily can
consume quite a bit of power.

So you'd have to add an API to cancel it again, but then realistically
we'd probably want to be able to cancel it if userspace forgets (ie.
give it a timeout), at which point it's basically equivalent to a
longer-than-you-needed remain-on-channel that you cancel after you're
done?

johannes

Re: Adding CMD_SET_CHANNEL for station iftypes

[James Prestwood]

Hi Johannes,

On Fri, 2021-11-19 at 09:31 +0100, Johannes Berg wrote:
> On Thu, 2021-11-18 at 16:11 -0800, James Prestwood wrote:
> > Hi,
> > 
> > I see CMD_SET_CHANNEL is only supported for AP-type iftypes (AP,
> > P2P_GO, etc). While this definitely makes sense in most cases,
> > protocols like p2p/dpp require going off channel for an
> > undetermined
> > amount of time.
> > 
> > I could go into the exact scenarios but in short your
> > REMAIN_ON_CHANNEL
> > could end at very inconvenient times.
> > 
> > Specifically when a station is not associated to any AP is there
> > any
> > harm in allowing CMD_SET_CHANNEL? Is this purely a software
> > limitation
> > or do drivers not allow this?
> > 
> > If this sounds reasonable (and possible)
> 
> I don't think this *works* because you don't have a way to say "I
> want
> to now go back to idle". And sitting on a channel arbitrarily can
> consume quite a bit of power.
> 
> So you'd have to add an API to cancel it again, but then
> realistically
> we'd probably want to be able to cancel it if userspace forgets (ie.
> give it a timeout), at which point it's basically equivalent to a
> longer-than-you-needed remain-on-channel that you cancel after you're
> done?

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.

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.

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

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.

Thanks,
James


> 
> johannes

Re: Adding CMD_SET_CHANNEL for station iftypes

[Johannes Berg]

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.

> 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. (*)

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.


(*) 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

Re: Adding CMD_SET_CHANNEL for station iftypes

[James Prestwood]

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

Re: Adding CMD_SET_CHANNEL for station iftypes

[Arend van Spriel]

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

Re: Adding CMD_SET_CHANNEL for station iftypes

[James Prestwood]

Hi Arend,

On Sun, 2022-01-09 at 13:00 +0100, Arend van Spriel wrote:
> 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?

Correct, I'm only talking about doing this while not associated.

As for my intentended scenario I simply want to call CMD_SET_CHANNEL
then run the entire DPP auth/config protocol while on this channel.
Then, once finished, call (a new API) CMD_SET_CHANNEL_CANCEL.

Currently I'm stuck doing CMD_REMAIN_ON_CHANNEL over and over. Which
leaves moments of time where the device is idle, potentially missing
DPP frames. This is especially bad for drivers which choose short ROC
timeouts. Also, since the ROC duration isn't honored userspace has to
manage its own separate timer and re-issue ROC if the driver decided to
use a different timeout. It just ends up being a mess and extremely
overcomplicated for something as simple as going offchannel. I feel
there has got to be a cleaner way to handle this.

P2P has a similar use case discovering peers AFAIK.

Thanks,
James

> 
> Regards,
> Arend
> 
> 

Re: Adding CMD_SET_CHANNEL for station iftypes

[Johannes Berg]

On Mon, 2022-01-10 at 09:13 -0800, James Prestwood wrote:
> > 
> > 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?
> 
> Correct, I'm only talking about doing this while not associated.
> 
> As for my intentended scenario I simply want to call CMD_SET_CHANNEL
> then run the entire DPP auth/config protocol while on this channel.
> Then, once finished, call (a new API) CMD_SET_CHANNEL_CANCEL.
> 

So I think Arend and I are approaching this from a different angle :-)

I was mostly thinking about the iwlwifi firmware implementation, to be
honest, which simply doesn't have such a thing today. The closest would
probably be putting it into monitor mode, which of course means you
don't get proper ACK behaviour etc.

I think Arend was probably more thinking of semantics rather than
implementation, surely it'd be _possible_ to do it, but it's not
something that you can _practically_ do today on all hardware.

So practically, if we add such API

 1) it might fix the issue on some devices that can implement it

 2) it would leave us having to emulate it using remain-on-channel or
    similar when the firmware doesn't support

 3) you'd still have to implement it for older kernels

(or we leave out 2, and you have to have the implementation for 3 for
newer kernels too)

I guess I wouldn't particularly mind adding APIs for it, but I'm not
sure I'd want to have to implement and maintain (2).

johannes