Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a5c2cbdc9f0c1587f0d27850ca3bbac2d5103e9c.camel@sipsolutions.net>
Subject: Re: Adding CMD_SET_CHANNEL for station iftypes
From:   Johannes Berg <johannes@sipsolutions.net>
To:     James Prestwood <prestwoj@gmail.com>,
        Arend van Spriel <aspriel@gmail.com>,
        linux-wireless@vger.kernel.org
Date:   Thu, 03 Feb 2022 23:06:50 +0100
In-Reply-To: <8557b62e0f1c6a94f7ec9b27a596d7499fd072d7.camel@gmail.com>
References: <2b18f86924c3d64437aa139f6401ee2e7705eeb0.camel@gmail.com>
         <47ba74aa23a5c4fb42660d5b40e974c24acf24bf.camel@sipsolutions.net>
         <91d38c40a62100dc6355c98e85b8b793ed8890df.camel@gmail.com>
         <d8250f97a2be736736374974095f219d858acb1e.camel@sipsolutions.net>
         <58ebff51d64d1ae6b01d85cff7bb9e137e19848a.camel@gmail.com>
         <17e3eb62ed0.279b.9696ff82abe5fb6502268bdc3b0467d4@gmail.com>
         <8557b62e0f1c6a94f7ec9b27a596d7499fd072d7.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.3 (3.42.3-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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