Re: [PATCH 10/21] offchannel: add support to issue multiple offchannel requests

[James Prestwood <prestwoj@gmail.com>]

Hi Denis,

On 10/19/23 2:42 PM, Denis Kenzior wrote:
> Hi James,
> 
>>
>> It wouldn't hurt, but I think we were always under the assuming that 
>> the ack would come before the event so I never bothered using a 
>> callback :)
>>
> 
> My memory is fuzzy now, but I think brcmfmac was very weird in this 
> area.  Which might explain why offchannel code is written the way it is.

I think Andrew sorted much of that out in frame-xchg, and I think there 
are comments about similar behavior of acks arriving late. I can dig up 
a brcmfmac card and play around with it.

> 
>>>
>>>> src/offchannel.c:offchannel_mlme_notify() ROC cancel, cookie=1
>>>>
>>>> # Cancel ROC is correctly waited for before starting the next item
>>>> src/wiphy.c:wiphy_radio_work_done() Work item 1 done
>>>> src/wiphy.c:wiphy_radio_work_next() Starting work item 2
>>>> src/offchannel.c:offchannel_work_ready() Issuing ROC
>>>> src/netdev.c:netdev_mlme_notify() MLME notification Remain on 
>>>> Channel(55)
>>>
>>> This seems fishy?  What else is going offchannel?
>>
>> No, this is the same event as below, just netdev printing it.
> 
> Ah, ok.
> 
>>
>>>
>>>>
>>>> # Then immediately we get a Remain on Channel event
>>>> src/offchannel.c:offchannel_mlme_notify() ROC notify, cookie=3
>>>> src/offchannel.c:offchannel_mlme_notify() ROC started prior to ACK, 
>>>> setting cookie 3
>>>> src/dpp.c:dpp_send_frame() Sending frame on frequency 2437
>>>>
>>>> # And finally the ack comes in
>>>> src/offchannel.c:offchannel_roc_cb() cookie=3
>>>
>>> Yeah, why is the cookie 3?  Shouldn't it be 2?
>>
>> 2 is the work item, 3 is the cookie above.
> 
> Yeah, I get that.  But shouldn't the cookie from the kernel be 2 and not 
> 3?  Or is the cookie also being incremented by CMD_FRAME?

Oh I see, since it jumped from 1 to 3. I would need to verify, but I'd 
guess yes the CMD_FRAME increments the same counter.

> 
> Regards,
> -Denis