| Message ID | 1383230452-12608-1-git-send-email-usdutt@qti.qualcomm.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? ???,j??f???h???z? ?w??? ???j:+v???w?j?m????????zZ+??????j"??!?i -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. 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 ?? ,j > f h z w j:+v w j m zZ+ ?j" ! i
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 ?? ,j >> f h z w > j:+v w j m zZ+ ?j" ! i > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 };
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(+)