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

[Denis Kenzior <denkenz@gmail.com>]

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