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
