Linux wireless drivers development
 help / color / mirror / Atom feed
From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
To: Denis Kenzior <denkenz@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: NL80211_SCAN_FLAG_RANDOM_ADDR ?
Date: Fri, 12 Apr 2019 09:26:28 +0000	[thread overview]
Message-ID: <20190412092623.46ygdnec3wx26zvd@bars> (raw)
In-Reply-To: <e09a9bc7-9774-334b-53e8-13e1d781bee3@gmail.com>

> I've been poking around at how this flag is used and I noticed this
> check in net/wireless/nl80211.c:
> 
> nl80211_check_scan_flags()
> 
>         if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) {
>                 int err;
> 
>                 if (!(wiphy->features & randomness_flag) ||
>                     (wdev && wdev->current_bss))
>                         return -EOPNOTSUPP;
> 
> 
> The above disallows the use of RANDOM_ADDR for scans while connected.
> The nl80211.h uapi header seems to concur:
> 
>  "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports
> using a random MAC address during scan (if the device is unassociated);"
> 
> However, if I create a P2P Device (in addition to the default STA
> device), the kernel happily lets me scan on the wdev while the STA
> interface is connected.
> 
> sudo iw phy0 interface add p2p type __p2pdev
> sudo iw wdev 0x2 p2p start
> sudo iw wdev 0x2 scan randomize
> 
> So the immediate question I have is, should the RANDOM_ADDR flag indeed
> be limited to unassociated STA interfaces?  It would seem the hardware
> is capable randomizing even when connected? Please educate me :)

Hello Denis,

IIUC, this feature could be introduced to support Android Compatibility
Definition Document (CDD). Those documents are available at the
following page: https://source.android.com/compatibility/cdd

For instance, in the latest CDD randomized scan requirements are described
in the section 7.4.2. It looks like current high level nl80211 API follows
those recommendations. Probably it has been implemented with STA use-case
in mind, that is why you can use that flag for P2P connection. But, as
Ben pointed out, actual application of this flag may depend on
implementation in firwmare and hardware.

Regards,
Sergey

  parent reply	other threads:[~2019-04-12  9:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 22:30 NL80211_SCAN_FLAG_RANDOM_ADDR ? Denis Kenzior
2019-04-11 23:19 ` Ben Greear
2019-04-11 23:20   ` Ben Greear
2019-04-12  1:26     ` Denis Kenzior
2019-04-12  2:15       ` Ben Greear
2019-04-12  9:26 ` Sergey Matyukevich [this message]
2019-04-12 15:00   ` Denis Kenzior
2019-04-12 21:21     ` Arend Van Spriel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190412092623.46ygdnec3wx26zvd@bars \
    --to=sergey.matyukevich.os@quantenna.com \
    --cc=denkenz@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox