Re: [RFC 0/1] Allow MAC change on up interface

[James Prestwood <prestwoj@gmail.com>]

On Tue, 2019-08-20 at 08:59 +0200, Johannes Berg wrote:
> Hi James,
> 
> Thanks for staying on topic.
> 
> > > 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.
> 
> :-)
> 
> I thought so, but I had another thought later. It might be possible
> to
> set LIVE_ADDR_CHANGE, but then block it in mac80211 when the
> interface
> is already connected (or beaconing, or whatever, using the MAC
> address
> in some way - even while scanning, remain-on-channel is active, etc.)

Yeah that makes sense.

> 
> I still think you'd have to bake it into the mac80211<->driver API
> somehow, because we normally "add_interface()" with the MAC address,
> and
> nothing says that the driver cannot ignore the MAC address from that
> point on. The fact that iwlwifi just copies it into every new
> MAC_CTXT
> command and the firmware actually accepts the update seems rather
> accidental and therefore fragile to rely on.

I havent looked into the actual drivers WRT add_interface so I'll take
a look. But I think I see the separation now and why it may not work
for all drivers/firmwares the way I did it.

So are you thinking we need another driver method:
"change_mac/set_mac"?

> 
> > The iwlwifi change was just an example. It ultimately would be up
> > to
> > the maintainers of each driver to support this or not. 
> 
> Sure. I was just trying to say what I wrote one paragraph up.
> 
> > > 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).
> 
> I see, at least sort of. I'm having a hard time seeing how this
> really
> is a problem in practice, but I suppose that's because I haven't
> tried
> implementing a fully event-driven stack.
> 
> > 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...
> 
> Interesting. I didn't think you'd do that, since it gives you far
> less
> control over things, and you need the other paths anyway for the
> features you mention, and the implementation in cfg80211 is far less
> complete than a typical firmware implementation would be.

There was talk about ditching CMD_CONNECT at one point, but for the
most part it does everything we need for the majority of connections.

But ultimately yes I think we do want this feature for
CMD_AUTHENTICATE/ASSOCIATE, and those details may be a bit more
involved. CMD_CONNECT was just an easier way to get my foot in the door
:)

Thanks,
James
> 
> johannes
>