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?). 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.
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?
Thanks,
James
Thanks,
James
