linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Prestwood <prestwoj@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC 0/1] Allow MAC change on up interface
Date: Mon, 19 Aug 2019 14:14:03 -0700	[thread overview]
Message-ID: <c6b719d6279211bbf52443f327884d96ef63f2b2.camel@gmail.com> (raw)
In-Reply-To: <4848c3a9d0b330fab4442436244387a2c127fa03.camel@sipsolutions.net>

Hi Johannes,

Without reiterating what Denis said:

<snip>

> I don't, short of
> 
> 1) don't do that then
> 2) extend the network stack to have
> IFF_LIVE_BUT_NO_CARRIER_ADDR_CHANGE
>    or something like that

So you mean 2 is my only option... ;) I am fine with this.

> 
> TBH, I'm not really sure I see any point in this to start with, many
> devices will give the address to the firmware when the interface is
> brought up (even iwlwifi does - I'm not sure we'd want to take your
> patch for iwlwifi even if that works today, nothing says the firmware
> might not change its mind on that), and so it's quite likely only
> going
> to be supported in few devices.

The iwlwifi change was just an example. It ultimately would be up to
the maintainers of each driver to support this or not. Regardless,
doing the ground work for a driver/firmware to support this is more
valuable than continuing to neglect these quirks that make use of
nl80211 difficult/racy.

> 
> You've also not really explained what exactly is troubling you with
> changing the MAC address, you just mentioned some sort of "race
> condition"?

In order to change the MAC on a per-AP/SSID is to: ifdown, change MAC,
ifup via RTNL. The problem is that ifdown generates an RTNL link down
event and there is no way of knowing how this event was generated (by
you, hot-unplug, or some other issue in kernel?). Handling this without
a race is simply not possible. You sort of just have to pray none of
this happens (and its unlikely but it *could* happen).

Besides efficiency another obvious reason for this change is simply
ease of use. If the hardware supports doing this then why should
userspace have to jump through hoops to accomplish it?

> 
> Now, one thing I can imagine would be that you'd want to optimize
> 
>  * ifdown
>    - remove iface from fw/hw
>    - stop fw/hw
>  * change MAC
>  * ifup
>    - start fw/hw
>    - add iface to fw/hw
> to just
> 
>  * ifdown
>    - remove iface from fw/hw
>  * change MAC
>  * ifup
>    - add iface to fw/hw
> 
> i.e. not restart the firmware (which takes time) for all this, but
> that
> seems much easier to solve by e.g. having a combined operation for
> all
> of this that gets handled in mac80211, or more generally by having a
> "please keep the firmware running" token that you can hold while you
> do
> the operation?
> 
> 
> Your changes are also a bit strange - you modified the "connect" path
> and iwlwifi, but the connect path is not usually (other than with iw
> or
> even iwconfig) taken for iwlwifi? And if you modify auth/assoc paths,
> you get into even weirder problems - what if you use different
> addresses
> for auth and assoc? What if the assoc (or even connect) really was a
> *re*assoc, and thus must have the same MAC address? To me, the whole
> thing seems like more of a problem than a solution.

The connect path is just what we (IWD) use for almost all types of
connections that support it (apart from things like SAE/OWE/FT). Not
sure what you mean for "usually not taken for iwlwifi"? If you have an
iwlwifi card and you issue CMD_CONNECT thats the path it takes...

Thanks,
James

> 
> johannes
> 


  parent reply	other threads:[~2019-08-19 21:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 18:57 [RFC 0/1] Allow MAC change on up interface James Prestwood
2019-08-15 18:57 ` [RFC 1/1] RFC: allow mac address change on up iface James Prestwood
2019-08-15 20:48 ` [RFC 0/1] Allow MAC change on up interface Jeff Johnson
2019-08-16  9:56   ` Toke Høiland-Jørgensen
2019-08-19 10:14 ` Johannes Berg
2019-08-19 15:55   ` James Prestwood
2019-08-19 20:20     ` Johannes Berg
2019-08-19 20:58       ` Denis Kenzior
2019-08-20  8:59         ` Johannes Berg
2019-08-20 15:40           ` Denis Kenzior
2019-08-20 17:53             ` Dan Williams
2019-08-20 18:21               ` Denis Kenzior
2019-08-20 18:54                 ` Toke Høiland-Jørgensen
2019-08-20 19:32             ` Johannes Berg
2019-08-20 19:46               ` Denis Kenzior
2019-08-20 20:01                 ` Johannes Berg
2019-08-19 21:14       ` James Prestwood [this message]
2019-08-20  6:59         ` Johannes Berg
2019-08-20 19:22           ` Denis Kenzior
2019-08-20 19:43             ` Johannes Berg
2019-08-20 19:58               ` Denis Kenzior
2019-08-20 20:15                 ` Johannes Berg
2019-08-20 20:37                   ` Denis Kenzior
2019-08-20 21:18                     ` Dan Williams
2019-08-20 21:52                       ` Denis Kenzior
2019-08-21  7:21                         ` Johannes Berg
2019-08-20 19:53           ` James Prestwood
2019-08-20 20:06             ` Johannes Berg

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=c6b719d6279211bbf52443f327884d96ef63f2b2.camel@gmail.com \
    --to=prestwoj@gmail.com \
    --cc=johannes@sipsolutions.net \
    --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;
as well as URLs for NNTP newsgroup(s).