Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.

[Jouni Malinen <j@w1.fi>]

On Fri, Nov 01, 2013 at 02:07:16PM +0100, Arend van Spriel wrote:
> On 11/01/2013 12:25 PM, Undekari, Sunil Dutt wrote:
> >The host driver / firmware performs (initiates) a scan on the STA interface in the process of finding a better BSS to roam. This scan is offloaded to the driver / firmware for a better roam experience.
> >This scans would definitely affect the p2p connection triggered by the supplicant.
> >Thus, I was suggesting a way to extend the already existing critical protocol indications to also include p2p protocol/connections, so that drivers can defer the scan's (any off channel operations for that matter) on any other interface during this period.
> 
> I got that. What I meant to say is that you can defer the roaming
> related scans when cfg80211 does a .add_virtual_intf() call to the
> driver and recommence upon .del_virtual_intf(). I guess this
> effectively disables roaming, right?

That sounds quite excessive. The case here is a multi-channel
concurrency capable device which has a station connection and
wpa_supplicant is about to go through P2P group formation. I see no
reason to disable roaming, but it would sound useful to avoid doing the
background scans for that at the exact time of the group formation
(couple of seconds in most cases).

Currently, there is no way for wpa_supplicant to clearly indicate to the
driver that it is about to run through number of quick operations
(offchannel Action frame exchange for GO Negotiation, single channel
scan, WPS association + EAPOL exchange, data connection association +
4-way handshake). The driver can guess that this is happening (or could
use really ugly hacks to see what Action frames are exchanged and
determine next likely operation based on that) and as such, would not
know how to configure the firmware to avoid background scans for the
station interface during this full sequence.

While the background scan should in most cases not completely break the
process even with inconvenient timing (or well, hitting one in middle of
the three frame GO Negotiation would have potential to time out that
exchange), it would be nice if this common sequence could be optimized
to avoid extra latencies and to be more robust in general since there is
a 15 second timeout for group formation and quite a bit shorter timeouts
in practice for the individual operations within the sequence.

-- 
Jouni Malinen                                            PGP id EFC895FA