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(). > 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... johannes
