Hi,
> > 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.
Hm. Not sure then? I guess then you'd be falling into the max duration
or so?
if (!local->ops->remain_on_channel) {
/* If there's no hardware remain-on-channel, and
* doing so won't push us over the maximum r-o-c
* we allow, then we can just add the new one to
* the list and mark it as having started now.
* If it would push over the limit, don't try to
* combine with other started ones (that haven't
* been running as long) but potentially sort it
* with others that had the same fate.
*/
unsigned long now = jiffies;
u32 elapsed = jiffies_to_msecs(now - tmp->start_time);
struct wiphy *wiphy = local->hw.wiphy;
u32 max_roc = wiphy->max_remain_on_channel_duration;
if (elapsed + roc->duration > max_roc) {
combine_started = false;
continue;
}
Or maybe that logic here is broken somewhat ...
> > 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.
Did you say hwsim? That'd be weird. Though in hwsim I think you have an
additional quirk - it never really *leaves* the original channel it's
connected on, it kind of sticks around on *both* which isn't real but
some kind of simplification there. We might want to fix that eventually.
But not sure it's connected already in this case?
> 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.
Right, that's pretty much the intent for this kind of thing. Similar in
P2P where we designed all this, really.
johannes
