* [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. @ 2013-10-31 14:40 Sunil Dutt Undekari 2013-10-31 14:43 ` Johannes Berg 0 siblings, 1 reply; 14+ messages in thread From: Sunil Dutt Undekari @ 2013-10-31 14:40 UTC (permalink / raw) To: linux-wireless; +Cc: j, usdutt 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 <usdutt@qti.qualcomm.com> --- 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-10-31 14:40 [PATCH] cfg80211: Introduce critical protocol indication for p2p connection Sunil Dutt Undekari @ 2013-10-31 14:43 ` Johannes Berg 2013-10-31 15:22 ` Undekari, Sunil Dutt 0 siblings, 1 reply; 14+ messages in thread From: Johannes Berg @ 2013-10-31 14:43 UTC (permalink / raw) To: Sunil Dutt Undekari; +Cc: linux-wireless, j 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-10-31 14:43 ` Johannes Berg @ 2013-10-31 15:22 ` Undekari, Sunil Dutt 2013-10-31 15:25 ` Johannes Berg 0 siblings, 1 reply; 14+ messages in thread From: Undekari, Sunil Dutt @ 2013-10-31 15:22 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, j@w1.fi 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-10-31 15:22 ` Undekari, Sunil Dutt @ 2013-10-31 15:25 ` Johannes Berg 2013-10-31 15:54 ` Undekari, Sunil Dutt 0 siblings, 1 reply; 14+ messages in thread From: Johannes Berg @ 2013-10-31 15:25 UTC (permalink / raw) To: Undekari, Sunil Dutt; +Cc: linux-wireless@vger.kernel.org, j@w1.fi 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-10-31 15:25 ` Johannes Berg @ 2013-10-31 15:54 ` Undekari, Sunil Dutt 2013-10-31 17:42 ` Arend van Spriel 0 siblings, 1 reply; 14+ messages in thread From: Undekari, Sunil Dutt @ 2013-10-31 15:54 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, j@w1.fi 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-10-31 15:54 ` Undekari, Sunil Dutt @ 2013-10-31 17:42 ` Arend van Spriel 2013-11-01 11:25 ` Undekari, Sunil Dutt 0 siblings, 1 reply; 14+ messages in thread From: Arend van Spriel @ 2013-10-31 17:42 UTC (permalink / raw) To: Undekari, Sunil Dutt Cc: Johannes Berg, linux-wireless@vger.kernel.org, j@w1.fi 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:johannes@sipsolutions.net] > Sent: Thursday, October 31, 2013 8:55 PM > To: Undekari, Sunil Dutt > Cc: linux-wireless@vger.kernel.org; j@w1.fi > 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�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!�i ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-10-31 17:42 ` Arend van Spriel @ 2013-11-01 11:25 ` Undekari, Sunil Dutt 2013-11-01 13:07 ` Arend van Spriel 0 siblings, 1 reply; 14+ messages in thread From: Undekari, Sunil Dutt @ 2013-11-01 11:25 UTC (permalink / raw) To: Arend van Spriel; +Cc: Johannes Berg, linux-wireless@vger.kernel.org, j@w1.fi 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== ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-11-01 11:25 ` Undekari, Sunil Dutt @ 2013-11-01 13:07 ` Arend van Spriel 2013-11-02 7:33 ` Jouni Malinen 0 siblings, 1 reply; 14+ messages in thread From: Arend van Spriel @ 2013-11-01 13:07 UTC (permalink / raw) To: Undekari, Sunil Dutt Cc: Johannes Berg, linux-wireless@vger.kernel.org, j@w1.fi 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:arend@broadcom.com] > Sent: Thursday, October 31, 2013 11:12 PM > To: Undekari, Sunil Dutt > Cc: Johannes Berg; linux-wireless@vger.kernel.org; j@w1.fi > 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:johannes@sipsolutions.net] >> Sent: Thursday, October 31, 2013 8:55 PM >> To: Undekari, Sunil Dutt >> Cc: linux-wireless@vger.kernel.org; j@w1.fi >> 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 \x1dʇڙ ,j >> f h z \x1e w > j:+v w j m zZ+ ݢj" ! i > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-11-01 13:07 ` Arend van Spriel @ 2013-11-02 7:33 ` Jouni Malinen 2013-11-02 10:37 ` Arend van Spriel 0 siblings, 1 reply; 14+ messages in thread From: Jouni Malinen @ 2013-11-02 7:33 UTC (permalink / raw) To: Arend van Spriel Cc: Undekari, Sunil Dutt, Johannes Berg, linux-wireless@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-11-02 7:33 ` Jouni Malinen @ 2013-11-02 10:37 ` Arend van Spriel 2013-11-08 15:06 ` Undekari, Sunil Dutt 2013-11-11 16:26 ` Johannes Berg 0 siblings, 2 replies; 14+ messages in thread From: Arend van Spriel @ 2013-11-02 10:37 UTC (permalink / raw) To: Jouni Malinen Cc: Undekari, Sunil Dutt, Johannes Berg, linux-wireless@vger.kernel.org, Dan Williams 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-11-02 10:37 ` Arend van Spriel @ 2013-11-08 15:06 ` Undekari, Sunil Dutt 2013-11-11 16:26 ` Johannes Berg 1 sibling, 0 replies; 14+ messages in thread From: Undekari, Sunil Dutt @ 2013-11-08 15:06 UTC (permalink / raw) To: Arend van Spriel, Jouni Malinen Cc: Johannes Berg, linux-wireless@vger.kernel.org, Dan Williams > 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:arend@broadcom.com] Sent: Saturday, November 02, 2013 4:07 PM To: Jouni Malinen Cc: Undekari, Sunil Dutt; Johannes Berg; linux-wireless@vger.kernel.org; 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-11-02 10:37 ` Arend van Spriel 2013-11-08 15:06 ` Undekari, Sunil Dutt @ 2013-11-11 16:26 ` Johannes Berg 2013-11-11 17:20 ` Dan Williams 1 sibling, 1 reply; 14+ messages in thread From: Johannes Berg @ 2013-11-11 16:26 UTC (permalink / raw) To: Arend van Spriel Cc: Jouni Malinen, Undekari, Sunil Dutt, linux-wireless@vger.kernel.org, Dan Williams 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. 2013-11-11 16:26 ` Johannes Berg @ 2013-11-11 17:20 ` Dan Williams [not found] ` <52811F6E.3010100@broadcom.com> 0 siblings, 1 reply; 14+ messages in thread From: Dan Williams @ 2013-11-11 17:20 UTC (permalink / raw) To: Johannes Berg Cc: Arend van Spriel, Jouni Malinen, Undekari, Sunil Dutt, linux-wireless@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <52811F6E.3010100@broadcom.com>]
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection. [not found] ` <52811F6E.3010100@broadcom.com> @ 2013-11-11 19:04 ` Dan Williams 0 siblings, 0 replies; 14+ messages in thread From: Dan Williams @ 2013-11-11 19:04 UTC (permalink / raw) To: Arend van Spriel Cc: Johannes Berg, Jouni Malinen, Undekari, Sunil Dutt, linux-wireless@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-11-11 19:04 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-31 14:40 [PATCH] cfg80211: Introduce critical protocol indication for p2p connection Sunil Dutt Undekari
2013-10-31 14:43 ` Johannes Berg
2013-10-31 15:22 ` Undekari, Sunil Dutt
2013-10-31 15:25 ` Johannes Berg
2013-10-31 15:54 ` Undekari, Sunil Dutt
2013-10-31 17:42 ` Arend van Spriel
2013-11-01 11:25 ` Undekari, Sunil Dutt
2013-11-01 13:07 ` Arend van Spriel
2013-11-02 7:33 ` Jouni Malinen
2013-11-02 10:37 ` Arend van Spriel
2013-11-08 15:06 ` Undekari, Sunil Dutt
2013-11-11 16:26 ` Johannes Berg
2013-11-11 17:20 ` Dan Williams
[not found] ` <52811F6E.3010100@broadcom.com>
2013-11-11 19:04 ` Dan Williams
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).