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]

 



>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.
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��������+%������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