All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: James Prestwood <prestwoj@gmail.com>, Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC 1/1] net: move IFF_LIVE_ADDR_CHANGE to public flag
Date: Tue, 09 Aug 2022 21:04:20 +0200	[thread overview]
Message-ID: <0fc27b144ca3adb4ff6b3057f2654040392ef2d8.camel@sipsolutions.net> (raw)
In-Reply-To: <f03b4330c7e9d131d9ad198900a3370de4508304.camel@gmail.com>

On Thu, 2022-08-04 at 12:49 -0700, James Prestwood wrote:
> > > 
> > > The semantics in wireless are also a little stretched because
> > > normally
> > > if the flag is not set the netdev will _refuse_ (-EBUSY) to change
> > > the
> > > address while running, not do some crazy fw reset.
> > 
> > Sorry if I wasn't clear, but its not nl80211 doing the fw reset
> > automatically. The wireless subsystem actually completely disallows a
> > MAC change if the device is running, this flag isn't even checked.
> > This
> > means userspace has to bring the device down itself, then change the
> > MAC.
> > 
> > I plan on also modifying mac80211 to first check this flag and allow
> > a
> > live MAC change if possible. But ultimately userspace still needs to
> > be
> > aware of the support.
> > 

I'm not sure this is the right approach.

For the stated purpose (not powering down the NIC), with most mac80211
drivers the following would work:

 - add a new virtual interface of any supported type, and bring it up
 - bring down the other interface, change MAC address, bring it up again
 - remove the interface added in step 1

though obviously that's not a good way to do it!

But internally in mac80211, there's a distinction between

 ->stop() to turn off the NIC, and
 ->remove_interface() to remove the interface.

Changing the MAC address should always be possible when the interface
doesn't exist in the driver (remove_interface), but without stop()ing
the NIC.

However, obviously remove_interface() implies that you break the
connection first, and obviously you cannot change the MAC address
without breaking the connection (stopping AP, etc.)

Therefore, the semantics of this flag don't make sense - you cannot
change the MAC address in a "live" way while there's a connection, and
at least internally you need not stop the NIC to change it. Since
ethernet has no concept of a "connection" in the same way, things are
different there.

Not sure how to really solve this - perhaps a wireless-specific way of
changing the MAC address could be added, though that's quite ugly, or we
might be able to permit changing the MAC address while not active in any
way (connected, scanning etc.) by removing from/re-adding to the driver
at least as far as mac80211 is concerned.

johannes

  reply	other threads:[~2022-08-09 19:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-04 17:43 [RFC 0/1] Move IFF_LIVE_ADDR_CHANGE to public flag James Prestwood
2022-08-04 17:43 ` [RFC 1/1] net: move " James Prestwood
2022-08-04 17:59   ` Stephen Hemminger
2022-08-04 19:29     ` James Prestwood
2022-08-04 18:43   ` Jakub Kicinski
2022-08-04 19:23     ` James Prestwood
2022-08-04 19:49       ` James Prestwood
2022-08-09 19:04         ` Johannes Berg [this message]
2022-08-10 16:26           ` James Prestwood
2022-08-10 17:17             ` Johannes Berg
2022-08-10 17:36               ` Jakub Kicinski
2022-08-10 19:35               ` James Prestwood
2022-08-04 20:49 ` [RFC 0/1] Move " Andrew Lunn

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=0fc27b144ca3adb4ff6b3057f2654040392ef2d8.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=prestwoj@gmail.com \
    /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.