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.) 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. > 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. johannes
