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 >
