A question on P2P Remain on channel (ROC)

[Jouni Malinen]

On Fri, Aug 07, 2015 at 01:05:03PM +0000, Atul Joshi wrote:
> 1.       The find phase is implemented in supplicant using ROC as follows
> a.       Scan on social channels
> b.      Create ROC with duration ~ {100/200/300 msec}
> c.       During the ROC if we  receive a probe request the probe response is sent.
> 2.       If during this ROC, a GO-negotiation.request is received, the supplicant send GO-negotiation.response and uses the wait_time as 500 msec.
> 3.       Since the current ROC may be active, then mac80211 will not send the frame as a part of the active ROC (since the duration required is < duration available)

I'm unable to reproduce this. I see GO Negotiation Response going out in
under 10 ms with mac80211_hwsim even in case where the existing ROC (for
300 TU in this specific case) is about to end in 80 ms. The
NL80211_CMD_FRAME_TX_STATUS event is also received within 2 ms from
having issued NL80211_CMD_FRAME which is pretty clear indication that
mac80211 sent the frame immediately.

Would you be able to share a wpa_supplicant debug log with timestamps
(-dt on command line) showing a case where the offloaded TX gets delayed
until the existing ROC completes? Which kernel version are you using?

> 4.       This will lead mac80211 to wait for the current ROC to finish and then schedule a new ROC
> 
> 5.       This in turn could lead to delays > 100 msec in sending GO-negotiation.response and the procedure would fail.
> In this case should the supplicant not stop ongoing ROC and restart the new one?

I would much rather see mac80211 extend the ROC if needed but anyway,
since I could not reproduce this, I'm not sure what more to say about
this before seeing a debug log showing the exact sequence and timing of
events.

-- 
Jouni Malinen                                            PGP id EFC895FA