All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Anatol Pomozov <anatol.pomozov@gmail.com>,
	"Greenman, Gregory" <gregory.greenman@intel.com>,
	linux-wireless@vger.kernel.org, "Grumbach,
	Emmanuel" <emmanuel.grumbach@intel.com>
Subject: Re: MAC address randomization support
Date: Tue, 01 Dec 2015 23:05:39 +0100	[thread overview]
Message-ID: <1449007539.2977.11.camel@sipsolutions.net> (raw)
In-Reply-To: <CAOMFOmV-TdX2h2patazVuffZmy=MAqHfnLso90kQn5+d=ODU9w@mail.gmail.com> (sfid-20151201_225959_079001_7630D8E2)

Hi Anatol,

> This feature is supported in Android and a few products use it
> already for Preferred Network Offload scan. There is a HAL method
> that allows to set MAC OUI [1] that makes 3 first octets predefined
> and the rest of MAC address is randomized. Kernel passes this OUI
> value to firmware where the randomization is implemented.
> 
> I checked current upstream kernel and did not find any API for
> enabling/dealing with MAC address randomization. If a firmware devs
> want to add the feature easily then there should be some standard API
> for enabling/configuring MAC randomization.

Well, we are treating it on a per-feature basis. The upstream kernel
does, in fact, and I believe we also submitted it into ChromeOS,
support randomized MAC addresses for scan and scheduled scan.

> In fact there is one mention of the feature in upstream source tree -
> macaddr_* fields in "struct iwl_tof_range_req_cmd" of iwlwifi driver.
> It allows to enable/disable randomization for 11MC measurement.

If you're talking about fine timing measurement, however, we haven't
yet submitted that API for that upstream. I sent you a draft of that
API and it does in fact contain MAC address randomization support from
the start :)

> The MAC randomization could be used by other drivers for many
> use-cases and I think it worth making it a part of standard cfg80211
> API. Is it something maintainers are interested in? Does anybody work
> on it already?

Yes and yes, obviously, but I think what I said at the beginning - that
it's per feature rather than global - is just not what you were looking
for or had expected?

I still think it makes sense btw, scan for example can be randomized in
software in certain cases, scheduled scan might not be able to, etc.

johannes


      reply	other threads:[~2015-12-01 22:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 21:59 MAC address randomization support Anatol Pomozov
2015-12-01 22:05 ` Johannes Berg [this message]

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=1449007539.2977.11.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=anatol.pomozov@gmail.com \
    --cc=emmanuel.grumbach@intel.com \
    --cc=gregory.greenman@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.