[PATCH] nl80211: add new scan flag to indicate P2P search

[PATCH] nl80211: add new scan flag to indicate P2P search

[Dedy Lansky]

Scan request (NL80211_CMD_TRIGGER_SCAN) is used for triggering both scan
and P2P search.
At driver/firmware layer, scan and P2P search might be handled differently.

Add new scan flag to indicate P2P search. This flag can be used
by applications (e.g. wpa_supplicant) to explicitly request P2P search.

Signed-off-by: Dedy Lansky <dlansky@codeaurora.org>
---
 include/uapi/linux/nl80211.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index f52797a..d7d07d6 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4383,12 +4383,14 @@ enum nl80211_connect_failed_reason {
  *	locally administered 1, multicast 0) is assumed.
  *	This flag must not be requested when the feature isn't supported, check
  *	the nl80211 feature flags for the device.
+ * @NL80211_SCAN_FLAG_P2P: indicate this is a request for a P2P search
  */
 enum nl80211_scan_flags {
 	NL80211_SCAN_FLAG_LOW_PRIORITY			= 1<<0,
 	NL80211_SCAN_FLAG_FLUSH				= 1<<1,
 	NL80211_SCAN_FLAG_AP				= 1<<2,
 	NL80211_SCAN_FLAG_RANDOM_ADDR			= 1<<3,
+	NL80211_SCAN_FLAG_P2P				= 1<<4,
 };
 
 /**
-- 
1.9.1

Re: [PATCH] nl80211: add new scan flag to indicate P2P search

[Johannes Berg]

On Sun, 2015-01-25 at 14:30 +0200, Dedy Lansky wrote:
> Scan request (NL80211_CMD_TRIGGER_SCAN) is used for triggering both scan
> and P2P search.
> At driver/firmware layer, scan and P2P search might be handled differently.
> 
> Add new scan flag to indicate P2P search. This flag can be used
> by applications (e.g. wpa_supplicant) to explicitly request P2P search.

I think this ship has sailed many months ago -- too late, you can never
rely on wpa_supplicant settings this flag.

If you need to distinguish, you should be able to advertise P2P-Device
supports, and then get P2P scans on the P2P-Device virtual interface.
Could be a pure driver thing of course.

johannes

Re: [PATCH] nl80211: add new scan flag to indicate P2P search

[Jouni Malinen]

On Mon, Jan 26, 2015 at 09:27:20AM +0100, Johannes Berg wrote:
> On Sun, 2015-01-25 at 14:30 +0200, Dedy Lansky wrote:
> > Scan request (NL80211_CMD_TRIGGER_SCAN) is used for triggering both scan
> > and P2P search.
> > At driver/firmware layer, scan and P2P search might be handled differently.
> > 
> > Add new scan flag to indicate P2P search. This flag can be used
> > by applications (e.g. wpa_supplicant) to explicitly request P2P search.
> 
> I think this ship has sailed many months ago -- too late, you can never
> rely on wpa_supplicant settings this flag.

I'm not sure I'd fully agree with that.. wpa_supplicant currently maps
its internal struct wpa_driver_scan_params::p2p_probe to
NL80211_ATTR_TX_NO_CCK_RATE (and also removal of CCK rates from
NL80211_ATTR_SCAN_SUPP_RATES). However, neither of these make much sense
in bands other than 2.4 GHz. There is ongoing effort in defining P2P
social channels on other bands and it would be useful to be prepared for
those with a clear nl80211 flag in scan parameters. P2P on those new
bands will require wpa_supplicant changes, so it is reasonable to assume
that a wpa_supplicant version that supports those bands will also
support this new flag.

> If you need to distinguish, you should be able to advertise P2P-Device
> supports, and then get P2P scans on the P2P-Device virtual interface.
> Could be a pure driver thing of course.

It would be unfortunate to force people to use P2P-Device for this.
 
-- 
Jouni Malinen                                            PGP id EFC895FA

RE: [PATCH] nl80211: add new scan flag to indicate P2P search

[Dedy Lansky]

Hi Johannes,

Following Jouni's comment, would you please re-consider?

Thanks,
 Dedy.

From: Jouni Malinen [mailto:j@w1.fi] 
Sent: Monday, January 26, 2015 11:58 AM
> On Mon, Jan 26, 2015 at 09:27:20AM +0100, Johannes Berg wrote:
> > On Sun, 2015-01-25 at 14:30 +0200, Dedy Lansky wrote:
> > > Scan request (NL80211_CMD_TRIGGER_SCAN) is used for triggering both 
> > > scan and P2P search.
> > > At driver/firmware layer, scan and P2P search might be handled
differently.
> > > 
> > > Add new scan flag to indicate P2P search. This flag can be used by 
> > > applications (e.g. wpa_supplicant) to explicitly request P2P search.
> > 
> > I think this ship has sailed many months ago -- too late, you can 
> > never rely on wpa_supplicant settings this flag.
> 
> I'm not sure I'd fully agree with that.. wpa_supplicant currently maps its
internal struct wpa_driver_scan_params::p2p_probe to
NL80211_ATTR_TX_NO_CCK_RATE (and also removal of CCK rates from
NL80211_ATTR_SCAN_SUPP_RATES). However, neither of these make much sense in
bands other than 2.4 GHz. There is ongoing effort in defining P2P social
channels on other bands and it would be useful to be prepared for those with
a clear nl80211 flag in scan parameters. P2P on those new bands will require
wpa_supplicant changes, so it is reasonable to assume that a wpa_supplicant
version that supports those bands will also support this new flag.
> 
> > If you need to distinguish, you should be able to advertise P2P-Device 
> > supports, and then get P2P scans on the P2P-Device virtual interface.
> > Could be a pure driver thing of course.
> 
> It would be unfortunate to force people to use P2P-Device for this.
>  
> -- 
> Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH] nl80211: add new scan flag to indicate P2P search

[Johannes Berg]

On Mon, 2015-01-26 at 11:58 +0200, Jouni Malinen wrote:

> > If you need to distinguish, you should be able to advertise P2P-Device
> > supports, and then get P2P scans on the P2P-Device virtual interface.
> > Could be a pure driver thing of course.
> 
> It would be unfortunate to force people to use P2P-Device for this.
 
Just for the record - we discussed this in Ottawa and as I understood it
you seemed not to object as much to P2P-Device as here originally.

In particular, we discussed the fact that P2P-Device can share MAC
addresses with the regular interface, but also from a 'foreign'
interface (i.e. a different NIC supporting e.g. different bands).

I'll drop all of this for now, at least until you investigate P2P-Device
support more thoroughly.

johannes