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

[Johannes Berg <johannes@sipsolutions.net>]

On Sat, 2013-11-02 at 11:37 +0100, Arend van Spriel wrote:

> > 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.
> 
> I wanted this API primarily to avoid drivers doing that kind of hacks so 
> I agree. It was intended to avoid extra latencies during IP connection 
> setup, which is probably happening right after the group formation. So I 
> recommend the connection managers to use this API. I think Dan Williams 
> did some initial implementation testing in NetworkManager and had some 
> concerns. I forgot about them completely so not sure how that ended.
> 
> > 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.
> 
> I guess the decision is for Johannes to take, but I see your point.

I think after this long discussion we all finally understand the concern
and use case - that really could have been explained in the patch
message.

Anyhow, I think that the critical protocol API is still a bad fit
because it currently only allows
 (1) a single user of the API at a time, so e.g. connman using it for
DHCP on a
     P2P group interface while wpa_s is using it for GO negotation would
break
 (2) changing that is probably not too difficult technically, but the
question is
     how multiple concurrent protocols should behave and if anything
else has
     really started using this yet
 (3) the existing protocols here are *data/payload* protocols, the new
protocol
     you're adding is more of a *management* protocol

johannes