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@xxxxxxxxxxxx]
Sent: Thursday, October 31, 2013 11:12 PM
To: Undekari, Sunil Dutt
Cc: Johannes Berg; linux-wireless@xxxxxxxxxxxxxxx; j@xxxxx
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@xxxxxxxxxxxxxxxx]
Sent: Thursday, October 31, 2013 8:55 PM
To: Undekari, Sunil Dutt
Cc: linux-wireless@xxxxxxxxxxxxxxx; j@xxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
