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

[Dan Williams <dcbw@redhat.com>]

On Mon, 2013-11-11 at 17:26 +0100, Johannes Berg wrote:
> 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

I've had patches for NetworkManager for a while for this, I had
developed them in May 2013 which then resulted in my replies to
"cfg80211: introduce critical protocol indication from user-space".  I
posted about your problem #1, and Arnd's reply at the time was "I am not
fully convinced there will be a need for multiple protocols."  Perhaps
that need has now become more apparent?

Dan