Message-ID: <91d38c40a62100dc6355c98e85b8b793ed8890df.camel@gmail.com>
Subject: Re: Adding CMD_SET_CHANNEL for station iftypes
From:   James Prestwood <prestwoj@gmail.com>
To:     Johannes Berg <johannes@sipsolutions.net>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Fri, 19 Nov 2021 09:43:25 -0800
In-Reply-To: <47ba74aa23a5c4fb42660d5b40e974c24acf24bf.camel@sipsolutions.net>
References: <2b18f86924c3d64437aa139f6401ee2e7705eeb0.camel@gmail.com>
         <47ba74aa23a5c4fb42660d5b40e974c24acf24bf.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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