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: <6d3869e9-6d8f-f7cf-2fe9-b8188a02d086@gmail.com>
Date:   Fri, 7 Apr 2023 11:47:44 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
Content-Language: en-US
To:     linux-wireless@vger.kernel.org
From:   James Prestwood <prestwoj@gmail.com>
Subject: CMD_REMAIN_ON_CHANNEL vs CMD_FRAME (offchannel)
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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?

Thanks,
James