Hi Johannes,
So keeping things purely technical now :)
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.)
Here's what we would like to see:
- The ability for userspace to add a 'Local Mac Address to use'
attribute on CMD_CONNECT and CMD_AUTHENTICATE.
- It doesn't seem useful to add this to CMD_ASSOCIATE at the moment, as
for new connections you'd always go either through CMD_AUTHENTICATE,
CMD_ASSOCIATE sequence or use CMD_CONNECT. This should take care of
some (most) of your objections about specifying different addresses for
authenticate/associate. Feel free to correct me here.
- For Fast Transitions, Re-associations, roaming, etc userspace would
simply omit the 'Local Mac Address to use' attribute and the currently
set address would be used.
- Optionally (and I'm thinking of tools like NM here), add the ability
to set the mac address via RTNL while the device is UP but has no
carrier, and things like scanning, offchannel, etc are not in progress.
Though really I don't see how NM could guarantee this without bringing
the device down first, so I'll let NM guys chime in to see if this is a
good idea.
- We definitely do not want to to mess with the device state otherwise.
E.g. no firmware downloading, powering the adapter down, etc. That just
takes too much time.
The goal here is to keep things as fast as possible. The randomization
feature is basically standard on every modern OS. So users expect it to
be used on every connection. Slowing down the connection time by up to
3 seconds just isn't acceptable.
So tell us what you would like to see. A new
IFF_NO_CARRIER_ADDRESS_CHANGE or whether it is possible to use
IFF_LIVE_ADDR_CHANGE with some additional restrictions.
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.
Since you seem to have a clear(er?) idea here, can you elaborate or
possibly provide the driver interface changes you want to see?
Regards,
-Denis
