Search Linux Wireless

RE: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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


��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux