A reliable P2P connection needs to avoid any offload off channel
operations triggered by the host driver.Thus, indicate such
attempts to the host driver by including a new protocol id,
signifying the p2p connection.
Signed-off-by: Sunil Dutt <[email protected]>
---
include/uapi/linux/nl80211.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 8f01961..cae07aa 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3894,6 +3894,7 @@ enum nl80211_protocol_features {
* @NL80211_CRIT_PROTO_DHCP: BOOTP or DHCPv6 protocol.
* @NL80211_CRIT_PROTO_EAPOL: EAPOL protocol.
* @NL80211_CRIT_PROTO_APIPA: APIPA protocol.
+ * @NL80211_CRIT_PROTO_P2P: P2P protocol.
* @NUM_NL80211_CRIT_PROTO: must be kept last.
*/
enum nl80211_crit_proto_id {
@@ -3901,6 +3902,7 @@ enum nl80211_crit_proto_id {
NL80211_CRIT_PROTO_DHCP,
NL80211_CRIT_PROTO_EAPOL,
NL80211_CRIT_PROTO_APIPA,
+ NL80211_CRIT_PROTO_P2P,
/* add other protocols before this one */
NUM_NL80211_CRIT_PROTO
};
--
1.8.2.1
On Thu, 2013-10-31 at 20:10 +0530, Sunil Dutt Undekari wrote:
> A reliable P2P connection needs to avoid any offload off channel
> operations triggered by the host driver.
That's not what the critical protocol stuff was designed for, so no.
johannes
Pkp1c3QgZG8gaXQgaW4gdGhlIHN1cHBsaWNhbnQgLSB0aGF0IGhhcyBmdWxsIGNvbnRyb2wgb3Zl
ciB3aGF0J3MgZ29pbmcgb24gd2l0aCBhIGdpdmVuIGRldmljZS4NCj5UcnlpbmcgdG8gaGF2ZSB0
aGUga2VybmVsIG1hbmFnZSBtdWx0aXBsZSB0aGluZ3MgdGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBl
eGNsdXNpdmUgYW5kIGFyZSBhbGwgZG9uZSBpbiB1c2Vyc3BhY2UgaXMgZ29pbmcgdG8gYmUgYSBm
dXRpbGUgZXhlcmNpc2UuDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBzY2FucyB0aGF0IGFyZSBtZW50
aW9uZWQgYnkgbWUgaW4gdGhpcyBjb250ZXh0IGFyZSBub3QgdHJpZ2dlcmVkIGJ5IHRoZSBzdXBw
bGljYW50LCByYXRoZXIgdGhlIGhvc3QgZHJpdmVyIHdvdWxkIGluaXRpYXRlIHRoZW0uDQpUaGUg
ZHJpdmVyIC8gZmlybXdhcmUgd291bGQgZG8gc3VjaCBzY2FucyBmb3IgYSBiZXR0ZXIgcm9hbSBw
ZXJmb3JtYW5jZS4NCkkgd291bGQgc2F5LCBzb21lIGhhbmRzaGFrZSBiZXR3ZWVuIHRoZSBzdXBw
bGljYW50IGFuZCB0aGUgZHJpdmVyIHdvdWxkIGJlIG5lZWRlZCBmb3IgYSBiZXR0ZXIgdW5kZXJz
dGFuZGluZyBvbiB0aGUgb3BlcmF0aW9ucy4NClBsZWFzZSBoYXZlIHlvdXIgc2F5Lg0KUmVnYXJk
cywNClN1bmlsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hhbm5lcyBC
ZXJnIFttYWlsdG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0gDQpTZW50OiBUaHVyc2RheSwg
T2N0b2JlciAzMSwgMjAxMyA4OjU1IFBNDQpUbzogVW5kZWthcmksIFN1bmlsIER1dHQNCkNjOiBs
aW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IGpAdzEuZmkNClN1YmplY3Q6IFJlOiBbUEFU
Q0hdIGNmZzgwMjExOiBJbnRyb2R1Y2UgY3JpdGljYWwgcHJvdG9jb2wgaW5kaWNhdGlvbiBmb3Ig
cDJwIGNvbm5lY3Rpb24uDQoNCk9uIFRodSwgMjAxMy0xMC0zMSBhdCAxNToyMiArMDAwMCwgVW5k
ZWthcmksIFN1bmlsIER1dHQgd3JvdGU6DQo+ID4gVGhhdCdzIG5vdCB3aGF0IHRoZSBjcml0aWNh
bCBwcm90b2NvbCBzdHVmZiB3YXMgZGVzaWduZWQgZm9yLCBzbyBuby4NCj4gSSB3b3VsZCBjb25z
aWRlciB0aGUgUDJQIGNvbm5lY3Rpb24gcGhhc2UgKFAyUCtXUFMrV1BBKSB0byBiZSBjcml0aWNh
bCANCj4gYW5kIGFueSBvZmYgY2hhbm5lbCBvcGVyYXRpb25zIChzY2FuKSB0cmlnZ2VyZWQgYnkg
dGhlIGhvc3QgZHJpdmVyIA0KPiB3b3VsZCByZXN1bHQgaW4gdGhlIGRlbGF5ZWQgLyBmYWlsZWQg
UDJQIGNvbm5lY3Rpb24gYXR0ZW1wdC4NCj4gSSBzdXBwb3NlIHRoZXJlIHNob3VsZCBiZSBhbiBp
bmRpY2F0aW9uIHRvIHRoZSBob3N0IGRyaXZlciB3LnIudCBwMnAgDQo+IGNvbm5lY3Rpb24gYXR0
ZW1wdCBzbyB0aGF0IGFueSBvZmYgbG9hZCBvcGVyYXRpb25zIG9uIGFueSBvdGhlciANCj4gaW50
ZXJmYWNlIHNoYXJpbmcgdGhlIHNhbWUgcmFkaW8gd291bGQgYmUgYXZvaWRlZCBieSB0aGUgZHJp
dmVyLg0KPiBTaW5jZSB0aGVyZSBpcyBhbHJlYWR5IGFuIGV4aXN0aW5nIGludGVyZmFjZSB0aHJv
dWdoIHRoZSBjcml0aWNhbCANCj4gcHJvdG9jb2wgaW5kaWNhdGlvbiwgSSB0aG91Z2h0IG9mIGV4
dGVuZGluZyBpdCB0byBhbHNvIGluY2x1ZGUgYSBQMlAgDQo+IHByb3RvY29sL2Nvbm5lY3Rpb24u
IFRoaXMgbmV3IHByb3RvIGlkIHdvdWxkIGJlIGFuIGluZGljYXRpb24gdG8gdGhlIA0KPiBkcml2
ZXJzIHRvIGFsbG93IHRoZSBzY2FuIG9uIHRoZSBjdXJyZW50IGludGVyZmFjZSBhbmQgYXZvaWQg
YW55IHNjYW5zIA0KPiBvbiBhbm90aGVyIGNvbnNpZGVyaW5nIHRoZSBmYWN0IHRoYXQgYSBwMnAg
Y29ubmVjdGlvbiByZXF1aXJlcyBhIHNjYW4uDQo+IERvIHlvdSBwcm9wb3NlIGFuIGFsdGVybmF0
aXZlIChhIG5ldyBpbnRlcmZhY2U/KSB0byBhY2hpZXZlIHRoZSBzYW1lPw0KDQpKdXN0IGRvIGl0
IGluIHRoZSBzdXBwbGljYW50IC0gdGhhdCBoYXMgZnVsbCBjb250cm9sIG92ZXIgd2hhdCdzIGdv
aW5nIG9uIHdpdGggYSBnaXZlbiBkZXZpY2UuDQoNClRyeWluZyB0byBoYXZlIHRoZSBrZXJuZWwg
bWFuYWdlIG11bHRpcGxlIHRoaW5ncyB0aGF0IG1heSBvciBtYXkgbm90IGJlIGV4Y2x1c2l2ZSBh
bmQgYXJlIGFsbCBkb25lIGluIHVzZXJzcGFjZSBpcyBnb2luZyB0byBiZSBhIGZ1dGlsZSBleGVy
Y2lzZS4NCg0Kam9oYW5uZXMNCg0K
PiBUaGF0J3Mgbm90IHdoYXQgdGhlIGNyaXRpY2FsIHByb3RvY29sIHN0dWZmIHdhcyBkZXNpZ25l
ZCBmb3IsIHNvIG5vLg0KSSB3b3VsZCBjb25zaWRlciB0aGUgUDJQIGNvbm5lY3Rpb24gcGhhc2Ug
KFAyUCtXUFMrV1BBKSB0byBiZSBjcml0aWNhbCANCmFuZCBhbnkgb2ZmIGNoYW5uZWwgb3BlcmF0
aW9ucyAoc2NhbikgdHJpZ2dlcmVkIGJ5IHRoZSBob3N0IGRyaXZlciB3b3VsZCByZXN1bHQgaW4g
DQp0aGUgZGVsYXllZCAvIGZhaWxlZCBQMlAgY29ubmVjdGlvbiBhdHRlbXB0Lg0KSSBzdXBwb3Nl
IHRoZXJlIHNob3VsZCBiZSBhbiBpbmRpY2F0aW9uIHRvIHRoZSBob3N0IGRyaXZlciB3LnIudCBw
MnAgY29ubmVjdGlvbiANCmF0dGVtcHQgc28gdGhhdCBhbnkgb2ZmIGxvYWQgb3BlcmF0aW9ucyBv
biBhbnkgb3RoZXIgaW50ZXJmYWNlIHNoYXJpbmcgdGhlIHNhbWUgcmFkaW8gDQp3b3VsZCBiZSBh
dm9pZGVkIGJ5IHRoZSBkcml2ZXIuDQpTaW5jZSB0aGVyZSBpcyBhbHJlYWR5IGFuIGV4aXN0aW5n
IGludGVyZmFjZSB0aHJvdWdoIHRoZSBjcml0aWNhbCBwcm90b2NvbCBpbmRpY2F0aW9uLCBJIA0K
dGhvdWdodCBvZiBleHRlbmRpbmcgaXQgdG8gYWxzbyBpbmNsdWRlIGEgUDJQIHByb3RvY29sL2Nv
bm5lY3Rpb24uIFRoaXMgbmV3IHByb3RvIGlkIA0Kd291bGQgYmUgYW4gaW5kaWNhdGlvbiB0byB0
aGUgZHJpdmVycyB0byBhbGxvdyB0aGUgc2NhbiBvbiB0aGUgY3VycmVudCBpbnRlcmZhY2UgDQph
bmQgYXZvaWQgYW55IHNjYW5zIG9uIGFub3RoZXIgY29uc2lkZXJpbmcgdGhlIGZhY3QgdGhhdCBh
IHAycCBjb25uZWN0aW9uIHJlcXVpcmVzIGEgIA0Kc2Nhbi4NCkRvIHlvdSBwcm9wb3NlIGFuIGFs
dGVybmF0aXZlIChhIG5ldyBpbnRlcmZhY2U/KSB0byBhY2hpZXZlIHRoZSBzYW1lPw0KDQpSZWdh
cmRzLA0KU3VuaWwNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
Sm9oYW5uZXMgQmVyZyBbbWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdIA0KU2VudDog
VGh1cnNkYXksIE9jdG9iZXIgMzEsIDIwMTMgODoxMyBQTQ0KVG86IFVuZGVrYXJpLCBTdW5pbCBE
dXR0DQpDYzogbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnOyBqQHcxLmZpDQpTdWJqZWN0
OiBSZTogW1BBVENIXSBjZmc4MDIxMTogSW50cm9kdWNlIGNyaXRpY2FsIHByb3RvY29sIGluZGlj
YXRpb24gZm9yIHAycCBjb25uZWN0aW9uLg0KDQpPbiBUaHUsIDIwMTMtMTAtMzEgYXQgMjA6MTAg
KzA1MzAsIFN1bmlsIER1dHQgVW5kZWthcmkgd3JvdGU6DQo+IEEgcmVsaWFibGUgUDJQIGNvbm5l
Y3Rpb24gbmVlZHMgdG8gYXZvaWQgYW55IG9mZmxvYWQgb2ZmIGNoYW5uZWwgDQo+IG9wZXJhdGlv
bnMgdHJpZ2dlcmVkIGJ5IHRoZSBob3N0IGRyaXZlci4NCg0KVGhhdCdzIG5vdCB3aGF0IHRoZSBj
cml0aWNhbCBwcm90b2NvbCBzdHVmZiB3YXMgZGVzaWduZWQgZm9yLCBzbyBuby4NCg0Kam9oYW5u
ZXMNCg0K
On 10/31/13 16:54, Undekari, Sunil Dutt wrote:
>> Just do it in the supplicant - that has full control over what's going on with a given device.
>> Trying to have the kernel manage multiple things that may or may not be exclusive and are all done in userspace is going to be a futile exercise.
> Please note that the scans that are mentioned by me in this context are not triggered by the supplicant, rather the host driver would initiate them.
So how would the scenario look like. The host driver will get involved
in setting up the P2P connection so that knowledge is already available
to defer the scans or am I missing something.
Regards,
Arend
> The driver / firmware would do such scans for a better roam performance.
> I would say, some handshake between the supplicant and the driver would be needed for a better understanding on the operations.
> Please have your say.
> Regards,
> Sunil
>
> -----Original Message-----
> From: Johannes Berg [mailto:[email protected]]
> Sent: Thursday, October 31, 2013 8:55 PM
> To: Undekari, Sunil Dutt
> Cc: [email protected]; [email protected]
> Subject: Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
>
> On Thu, 2013-10-31 at 15:22 +0000, Undekari, Sunil Dutt wrote:
>>> That's not what the critical protocol stuff was designed for, so no.
>> I would consider the P2P connection phase (P2P+WPS+WPA) to be critical
>> and any off channel operations (scan) triggered by the host driver
>> would result in the delayed / failed P2P connection attempt.
>> I suppose there should be an indication to the host driver w.r.t p2p
>> connection attempt so that any off load operations on any other
>> interface sharing the same radio would be avoided by the driver.
>> Since there is already an existing interface through the critical
>> protocol indication, I thought of extending it to also include a P2P
>> protocol/connection. This new proto id would be an indication to the
>> drivers to allow the scan on the current interface and avoid any scans
>> on another considering the fact that a p2p connection requires a scan.
>> Do you propose an alternative (a new interface?) to achieve the same?
>
> Just do it in the supplicant - that has full control over what's going on with a given device.
>
> Trying to have the kernel manage multiple things that may or may not be exclusive and are all done in userspace is going to be a futile exercise.
>
> johannes
>
> N�����r��y���b�X��ǧv�^�){.n�+����{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w��� ���j:+v���w�j�m��������zZ+�����ݢj"��!�i
On Thu, 2013-10-31 at 15:22 +0000, Undekari, Sunil Dutt wrote:
> > That's not what the critical protocol stuff was designed for, so no.
> I would consider the P2P connection phase (P2P+WPS+WPA) to be critical
> and any off channel operations (scan) triggered by the host driver would result in
> the delayed / failed P2P connection attempt.
> I suppose there should be an indication to the host driver w.r.t p2p connection
> attempt so that any off load operations on any other interface sharing the same radio
> would be avoided by the driver.
> Since there is already an existing interface through the critical protocol indication, I
> thought of extending it to also include a P2P protocol/connection. This new proto id
> would be an indication to the drivers to allow the scan on the current interface
> and avoid any scans on another considering the fact that a p2p connection requires a
> scan.
> Do you propose an alternative (a new interface?) to achieve the same?
Just do it in the supplicant - that has full control over what's going
on with a given device.
Trying to have the kernel manage multiple things that may or may not be
exclusive and are all done in userspace is going to be a futile
exercise.
johannes
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
On 11/02/13 08:33, Jouni Malinen wrote:
> 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).
This is why I was asking for a more detailed usage scenario. Sunil only
mentioned the term "P2P connection" which seemed to coarse for this API.
So if we are talking about P2P group formation it makes sense.
> 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.
Regards,
Arend
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
> I guess the decision is for Johannes to take, but I see your point.
Johannes, please have your say.
Regards,
Sunil
-----Original Message-----
From: Arend van Spriel [mailto:[email protected]]
Sent: Saturday, November 02, 2013 4:07 PM
To: Jouni Malinen
Cc: Undekari, Sunil Dutt; Johannes Berg; [email protected]; Dan Williams
Subject: Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
On 11/02/13 08:33, Jouni Malinen wrote:
> 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).
This is why I was asking for a more detailed usage scenario. Sunil only mentioned the term "P2P connection" which seemed to coarse for this API.
So if we are talking about P2P group formation it makes sense.
> 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.
Regards,
Arend
On Mon, 2013-11-11 at 19:18 +0100, Arend van Spriel wrote:
> On 11/11/2013 06:20 PM, Dan Williams wrote:
> > 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?
>
> I don't know what Arnd said, but I went digging in my mailbox and I can
> not deny saying that :-p To put it into context I attached the message
> holding that statement. I guess our conversation never converged to a
> proper follow-up. See if we can do better this time around.
Sorry, I meant you, Arend :) Lack of convergence was partly my fault, I
had to switch off to other things. However, I think it's safest, most
technically correct, and best to track each critical protocol
individually and only cease critical protocol behaviors when all
protocols are any of (1) removed via netlink, (2) timed out, or (3)
netlink port has been closed.
Dan
On 11/01/2013 12:25 PM, Undekari, Sunil Dutt wrote:
> Hi Arend,
>
>> So how would the scenario look like. The host driver will get involved in setting up the P2P connection so that knowledge is already available to defer the scans or am I missing something.
> The host driver shall perform the scan's to find a better BSS in the
> 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?
Regards,
Arend
> Regards,
> Sunil.
>
>
>
> -----Original Message-----
> From: Arend van Spriel [mailto:[email protected]]
> Sent: Thursday, October 31, 2013 11:12 PM
> To: Undekari, Sunil Dutt
> Cc: Johannes Berg; [email protected]; [email protected]
> Subject: Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
>
> On 10/31/13 16:54, Undekari, Sunil Dutt wrote:
>>> Just do it in the supplicant - that has full control over what's going on with a given device.
>>> Trying to have the kernel manage multiple things that may or may not be exclusive and are all done in userspace is going to be a futile exercise.
>> Please note that the scans that are mentioned by me in this context are not triggered by the supplicant, rather the host driver would initiate them.
>
> So how would the scenario look like. The host driver will get involved in setting up the P2P connection so that knowledge is already available to defer the scans or am I missing something.
>
> Regards,
> Arend
>
>> The driver / firmware would do such scans for a better roam performance.
>> I would say, some handshake between the supplicant and the driver would be needed for a better understanding on the operations.
>> Please have your say.
>> Regards,
>> Sunil
>>
>> -----Original Message-----
>> From: Johannes Berg [mailto:[email protected]]
>> Sent: Thursday, October 31, 2013 8:55 PM
>> To: Undekari, Sunil Dutt
>> Cc: [email protected]; [email protected]
>> Subject: Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
>>
>> On Thu, 2013-10-31 at 15:22 +0000, Undekari, Sunil Dutt wrote:
>>>> That's not what the critical protocol stuff was designed for, so no.
>>> I would consider the P2P connection phase (P2P+WPS+WPA) to be
>>> critical and any off channel operations (scan) triggered by the host
>>> driver would result in the delayed / failed P2P connection attempt.
>>> I suppose there should be an indication to the host driver w.r.t p2p
>>> connection attempt so that any off load operations on any other
>>> interface sharing the same radio would be avoided by the driver.
>>> Since there is already an existing interface through the critical
>>> protocol indication, I thought of extending it to also include a P2P
>>> protocol/connection. This new proto id would be an indication to the
>>> drivers to allow the scan on the current interface and avoid any
>>> scans on another considering the fact that a p2p connection requires a scan.
>>> Do you propose an alternative (a new interface?) to achieve the same?
>>
>> Just do it in the supplicant - that has full control over what's going on with a given device.
>>
>> Trying to have the kernel manage multiple things that may or may not be exclusive and are all done in userspace is going to be a futile exercise.
>>
>> johannes
>>
>> N r y b X ǧv ^ ){.n + { *ޕ , {ay ʇڙ ,j
>> f h z w
> j:+v w j m zZ+ ݢj" ! i
>
>
SGkgQXJlbmQsDQoNCj5TbyBob3cgd291bGQgdGhlIHNjZW5hcmlvIGxvb2sgbGlrZS4gVGhlIGhv
c3QgZHJpdmVyIHdpbGwgZ2V0IGludm9sdmVkIGluIHNldHRpbmcgdXAgdGhlIFAyUCBjb25uZWN0
aW9uIHNvIHRoYXQga25vd2xlZGdlIGlzIGFscmVhZHkgYXZhaWxhYmxlIHRvIGRlZmVyIHRoZSBz
Y2FucyBvciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nLg0KVGhlIGhvc3QgZHJpdmVyIHNoYWxsIHBl
cmZvcm0gdGhlIHNjYW4ncyB0byBmaW5kIGEgYmV0dGVyIEJTUyBpbiB0aGUgDQpUaGUgaG9zdCBk
cml2ZXIgLyBmaXJtd2FyZSBwZXJmb3JtcyAoaW5pdGlhdGVzKSBhIHNjYW4gb24gdGhlIFNUQSBp
bnRlcmZhY2UgaW4gdGhlIHByb2Nlc3Mgb2YgZmluZGluZyBhIGJldHRlciBCU1MgdG8gcm9hbS4g
VGhpcyBzY2FuIGlzIG9mZmxvYWRlZCB0byB0aGUgZHJpdmVyIC8gZmlybXdhcmUgZm9yIGEgYmV0
dGVyIHJvYW0gZXhwZXJpZW5jZS4NClRoaXMgc2NhbnMgd291bGQgZGVmaW5pdGVseSBhZmZlY3Qg
dGhlIHAycCBjb25uZWN0aW9uIHRyaWdnZXJlZCBieSB0aGUgc3VwcGxpY2FudC4NClRodXMsIEkg
d2FzIHN1Z2dlc3RpbmcgYSB3YXkgdG8gZXh0ZW5kIHRoZSBhbHJlYWR5IGV4aXN0aW5nIGNyaXRp
Y2FsIHByb3RvY29sIGluZGljYXRpb25zIHRvIGFsc28gaW5jbHVkZSBwMnAgcHJvdG9jb2wvY29u
bmVjdGlvbnMsIHNvIHRoYXQgZHJpdmVycyBjYW4gZGVmZXIgdGhlIHNjYW4ncyAoYW55IG9mZiBj
aGFubmVsIG9wZXJhdGlvbnMgZm9yIHRoYXQgbWF0dGVyKSBvbiBhbnkgb3RoZXIgaW50ZXJmYWNl
IGR1cmluZyB0aGlzIHBlcmlvZC4NClJlZ2FyZHMsDQpTdW5pbC4NCiAgDQoNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFyZW5kIHZhbiBTcHJpZWwgW21haWx0bzphcmVuZEBi
cm9hZGNvbS5jb21dIA0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMzEsIDIwMTMgMTE6MTIgUE0N
ClRvOiBVbmRla2FyaSwgU3VuaWwgRHV0dA0KQ2M6IEpvaGFubmVzIEJlcmc7IGxpbnV4LXdpcmVs
ZXNzQHZnZXIua2VybmVsLm9yZzsgakB3MS5maQ0KU3ViamVjdDogUmU6IFtQQVRDSF0gY2ZnODAy
MTE6IEludHJvZHVjZSBjcml0aWNhbCBwcm90b2NvbCBpbmRpY2F0aW9uIGZvciBwMnAgY29ubmVj
dGlvbi4NCg0KT24gMTAvMzEvMTMgMTY6NTQsIFVuZGVrYXJpLCBTdW5pbCBEdXR0IHdyb3RlOg0K
Pj4gSnVzdCBkbyBpdCBpbiB0aGUgc3VwcGxpY2FudCAtIHRoYXQgaGFzIGZ1bGwgY29udHJvbCBv
dmVyIHdoYXQncyBnb2luZyBvbiB3aXRoIGEgZ2l2ZW4gZGV2aWNlLg0KPj4gVHJ5aW5nIHRvIGhh
dmUgdGhlIGtlcm5lbCBtYW5hZ2UgbXVsdGlwbGUgdGhpbmdzIHRoYXQgbWF5IG9yIG1heSBub3Qg
YmUgZXhjbHVzaXZlIGFuZCBhcmUgYWxsIGRvbmUgaW4gdXNlcnNwYWNlIGlzIGdvaW5nIHRvIGJl
IGEgZnV0aWxlIGV4ZXJjaXNlLg0KPiBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBzY2FucyB0aGF0IGFy
ZSBtZW50aW9uZWQgYnkgbWUgaW4gdGhpcyBjb250ZXh0IGFyZSBub3QgdHJpZ2dlcmVkIGJ5IHRo
ZSBzdXBwbGljYW50LCByYXRoZXIgdGhlIGhvc3QgZHJpdmVyIHdvdWxkIGluaXRpYXRlIHRoZW0u
DQoNClNvIGhvdyB3b3VsZCB0aGUgc2NlbmFyaW8gbG9vayBsaWtlLiBUaGUgaG9zdCBkcml2ZXIg
d2lsbCBnZXQgaW52b2x2ZWQgaW4gc2V0dGluZyB1cCB0aGUgUDJQIGNvbm5lY3Rpb24gc28gdGhh
dCBrbm93bGVkZ2UgaXMgYWxyZWFkeSBhdmFpbGFibGUgdG8gZGVmZXIgdGhlIHNjYW5zIG9yIGFt
IEkgbWlzc2luZyBzb21ldGhpbmcuDQoNClJlZ2FyZHMsDQpBcmVuZA0KDQo+IFRoZSBkcml2ZXIg
LyBmaXJtd2FyZSB3b3VsZCBkbyBzdWNoIHNjYW5zIGZvciBhIGJldHRlciByb2FtIHBlcmZvcm1h
bmNlLg0KPiBJIHdvdWxkIHNheSwgc29tZSBoYW5kc2hha2UgYmV0d2VlbiB0aGUgc3VwcGxpY2Fu
dCBhbmQgdGhlIGRyaXZlciB3b3VsZCBiZSBuZWVkZWQgZm9yIGEgYmV0dGVyIHVuZGVyc3RhbmRp
bmcgb24gdGhlIG9wZXJhdGlvbnMuDQo+IFBsZWFzZSBoYXZlIHlvdXIgc2F5Lg0KPiBSZWdhcmRz
LA0KPiBTdW5pbA0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2hh
bm5lcyBCZXJnIFttYWlsdG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0NCj4gU2VudDogVGh1
cnNkYXksIE9jdG9iZXIgMzEsIDIwMTMgODo1NSBQTQ0KPiBUbzogVW5kZWthcmksIFN1bmlsIER1
dHQNCj4gQ2M6IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZzsgakB3MS5maQ0KPiBTdWJq
ZWN0OiBSZTogW1BBVENIXSBjZmc4MDIxMTogSW50cm9kdWNlIGNyaXRpY2FsIHByb3RvY29sIGlu
ZGljYXRpb24gZm9yIHAycCBjb25uZWN0aW9uLg0KPg0KPiBPbiBUaHUsIDIwMTMtMTAtMzEgYXQg
MTU6MjIgKzAwMDAsIFVuZGVrYXJpLCBTdW5pbCBEdXR0IHdyb3RlOg0KPj4+IFRoYXQncyBub3Qg
d2hhdCB0aGUgY3JpdGljYWwgcHJvdG9jb2wgc3R1ZmYgd2FzIGRlc2lnbmVkIGZvciwgc28gbm8u
DQo+PiBJIHdvdWxkIGNvbnNpZGVyIHRoZSBQMlAgY29ubmVjdGlvbiBwaGFzZSAoUDJQK1dQUytX
UEEpIHRvIGJlIA0KPj4gY3JpdGljYWwgYW5kIGFueSBvZmYgY2hhbm5lbCBvcGVyYXRpb25zIChz
Y2FuKSB0cmlnZ2VyZWQgYnkgdGhlIGhvc3QgDQo+PiBkcml2ZXIgd291bGQgcmVzdWx0IGluIHRo
ZSBkZWxheWVkIC8gZmFpbGVkIFAyUCBjb25uZWN0aW9uIGF0dGVtcHQuDQo+PiBJIHN1cHBvc2Ug
dGhlcmUgc2hvdWxkIGJlIGFuIGluZGljYXRpb24gdG8gdGhlIGhvc3QgZHJpdmVyIHcuci50IHAy
cCANCj4+IGNvbm5lY3Rpb24gYXR0ZW1wdCBzbyB0aGF0IGFueSBvZmYgbG9hZCBvcGVyYXRpb25z
IG9uIGFueSBvdGhlciANCj4+IGludGVyZmFjZSBzaGFyaW5nIHRoZSBzYW1lIHJhZGlvIHdvdWxk
IGJlIGF2b2lkZWQgYnkgdGhlIGRyaXZlci4NCj4+IFNpbmNlIHRoZXJlIGlzIGFscmVhZHkgYW4g
ZXhpc3RpbmcgaW50ZXJmYWNlIHRocm91Z2ggdGhlIGNyaXRpY2FsIA0KPj4gcHJvdG9jb2wgaW5k
aWNhdGlvbiwgSSB0aG91Z2h0IG9mIGV4dGVuZGluZyBpdCB0byBhbHNvIGluY2x1ZGUgYSBQMlAg
DQo+PiBwcm90b2NvbC9jb25uZWN0aW9uLiBUaGlzIG5ldyBwcm90byBpZCB3b3VsZCBiZSBhbiBp
bmRpY2F0aW9uIHRvIHRoZSANCj4+IGRyaXZlcnMgdG8gYWxsb3cgdGhlIHNjYW4gb24gdGhlIGN1
cnJlbnQgaW50ZXJmYWNlIGFuZCBhdm9pZCBhbnkgDQo+PiBzY2FucyBvbiBhbm90aGVyIGNvbnNp
ZGVyaW5nIHRoZSBmYWN0IHRoYXQgYSBwMnAgY29ubmVjdGlvbiByZXF1aXJlcyBhIHNjYW4uDQo+
PiBEbyB5b3UgcHJvcG9zZSBhbiBhbHRlcm5hdGl2ZSAoYSBuZXcgaW50ZXJmYWNlPykgdG8gYWNo
aWV2ZSB0aGUgc2FtZT8NCj4NCj4gSnVzdCBkbyBpdCBpbiB0aGUgc3VwcGxpY2FudCAtIHRoYXQg
aGFzIGZ1bGwgY29udHJvbCBvdmVyIHdoYXQncyBnb2luZyBvbiB3aXRoIGEgZ2l2ZW4gZGV2aWNl
Lg0KPg0KPiBUcnlpbmcgdG8gaGF2ZSB0aGUga2VybmVsIG1hbmFnZSBtdWx0aXBsZSB0aGluZ3Mg
dGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBleGNsdXNpdmUgYW5kIGFyZSBhbGwgZG9uZSBpbiB1c2Vy
c3BhY2UgaXMgZ29pbmcgdG8gYmUgYSBmdXRpbGUgZXhlcmNpc2UuDQo+DQo+IGpvaGFubmVzDQo+
DQo+IE4gICAgIHIgIHkgICBiIFggIMendiBeICneunsubiArICAgIHsgICrelSAsIHtheSAdyofa
mSAsaiANCj4gICBmICAgaCAgIHogHiB3ICAgDQogICBqOit2ICAgdyBqIG0gICAgICAgICB6Wisg
ICAgIN2iaiIgICEgaQ0KDQoNCg==
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