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: <98f53583-400d-665f-d264-92e9f3e67280@gmail.com>
Date:   Tue, 25 Apr 2023 10:53:53 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: CMD_REMAIN_ON_CHANNEL vs CMD_FRAME (offchannel)
Content-Language: en-US
To:     Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless@vger.kernel.org
References: <6d3869e9-6d8f-f7cf-2fe9-b8188a02d086@gmail.com>
 <9b4b6d3e-8840-f37a-52ec-6ea391fa67db@gmail.com>
 <f5d14ce0b5053e4a99529677614d6d6aa797ac81.camel@sipsolutions.net>
From:   James Prestwood <prestwoj@gmail.com>
In-Reply-To: <f5d14ce0b5053e4a99529677614d6d6aa797ac81.camel@sipsolutions.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Johannes,

On 4/24/23 10:36 AM, Johannes Berg wrote:
> On Mon, 2023-04-10 at 15:49 -0700, James Prestwood wrote:
>> On 4/7/23 11:47 AM, James Prestwood wrote:
>>> Hi,
>>>
>>> I'm having an issue with CMD_REMAIN_ON_CHANNEL taking a full second to
>>> become ready versus CMD_FRAME (offchannel_ok=1) which is quite fast.
>>> Under the hood it looks like both commands call
>>> ieee80211_start_roc_work() so its curious why one would take so long.
>>> I'm running this in UML so I shouldn't be hitting scheduling problems
>>> (at least that's how I understand UML).
>>>
>>> This happens during the DPP auth exchange, I can include a full log if
>>> desired, but this is the sequence:
>>>
>>> - Start ROC on 2417mhz
>>> - Wait for ROC event indicating we are offchannel
>>> - Receive DPP presence announcement from enrollee
>>> - Send DPP auth request, request enrollee switches to 2412mhz
>>> - Send Cancel ROC (and wait for confirmation)
>>>
>>> - Start ROC on 2412mhz
>>> - Oddly, receive the enrollees auth response before ROC event. So the
>>> driver _did_ switch channels.
>>> - ROC event comes about a second later, and enrollee has timed out
>>>
>>> So the driver is in fact going offchannel to 2412 and even receiving a
>>> frame. But for whatever reason it doesn't send the ROC event for a full
>>> second. Any idea why the ROC event is so delayed here?
>>
>> After a lot of kernel prints I think I know whats going on, but still
>> somewhat confused.
>>
>> It appears that sending a frame then immediately canceling the ROC
>> request is the issue. The kernel seems to be queuing the CMD_FRAME
>> rather than adding it to the ROC request (is this expected?).
>>
> 
> I can't tell with the information you gave - depends on the waiting
> period for a response frame you ask for, I guess? With HW ROC (if you're
> using iwlwifi) we cannot extend the previous period, see
> ieee80211_coalesce_hw_started_roc().

This is purely virtual at the moment, but in my case its looking like it 
cannot be extended either since the CMD_FRAME just queues a separate 
request.

>   
>> To simplify the above sequence without DPP specifics:
>>
>> ROC on 2417mhz
>> ...
>> Send frame on 2417mhz (queued)
>> Cancel ROC request.
>> ROC request on 2412mhz (queued)
>>
>> At this point the kernel waits for the first (canceled) ROC to complete,
>> then processes the frame request (which requires going offchannel
>> again). THEN its able to handle the second ROC request.
> 
> What are the durations asked for, and waiting for response or not?
> 
>> Anyways, maybe ROC is the wrong way to be doing this? It was convenient
>> because its much easier to set some ultimate timeout then fire off
>> frames as needed in that duration in addition to listening for presence
>> announcements... But maybe ROC is just very limited in what can be done?
>> and using CMD_FRAME + a duration is the only way the kernel can support
>> this nicely?
> 
> Not sure I understand this part. ROC is fine mostly for the "wait for
> some frame and send a response", but not so much suited for "send a
> frame and wait for a response" part. So 3-way-handshakes are iffy with
> it...

Yeah, and it actually has worked great for the entire DPP procedure 
using the same channel (presence -> auth request -> auth response -> 
auth confirm) assuming both sides respond in a timely fashion.

The comes when changing the channel after the auth request. The auth 
request gets queued separately, which then delays the ROC and we 
can't/shouldn't send anything until ROC starts. The only strange thing 
is we actually receive the auth response on the new channel before the 
ROC for that new channel even starts. Its like the hardware and driver 
aren't quite in sync.

But anyways I think its best to use ROC for presence (waiting for 
announcements) but then use CMD_FRAME for the rest of the protocol.

Thanks,
James


> 
> johannes