Re: How does IWD handle setting MAC address?

[Marcel Holtmann <marcel holtmann org>]

Hi Thomas,

> > I am in favor of address randomization even while it has limited
> > affect, but at least for background scanning it is useful. However
> > doing this via RTNL is causing a weird layer violation and all sorts
> > of potential races and issues. This needs to be done with full
> > awareness of cfg80211 and thus via nl80211. So iwd should do it. And
> > iwd should just expose an on/off switch for WiFi Privacy.
>
> TL;DR: the policy of which MAC address to use (and when) is flexible
> and present in NetworkManager configuration. And it's more then a
> simple randomize on/off switch.
>
> ===
> A smaller reason is, that some people have strong opinions and consider
> important which bits of the address to scramble (and choose a well
> known manufacturer OUI)[1].
> I personally don't agree with the importance of such considerations,
> but I'd like NetworkManager to be the first choice for people with this
> particular need -- regardless of whether this need is real or only
> perceived.
> In NM you can configure how the bits are scrambled very flexible. Both
> while scanning[2] and while being associated[3].
>
> More interesting is, I don't only want to have a random MAC address
> while scanning, but also while being associated. My permanent MAC
> address should never ever be reveiled.
> But a new random MAC address on each new association isn't exactly what you
> want either, because then I get a new IP address from DHCP each time and have
> to redo captive portal login.
> So, I want for each of my Wi-Fi profiles a different, stable MAC
> address. Actually, for public networks like a hotel, I want to use a
> stable MAC address for a limited amount of time. The example in [4]
> show how to do that in NM.
> ===

I have nothing against an option that says generate a new MAC address for this SSID and keep using it from 
that time forward. It is a bit counterproductive if nl80211 doesn’t allow to specify the MAC address for 
association. Since powering down WiFi, changing the address and powering back up is something that I am 
strictly against.

So if these things are what people really want, then neither NM nor iwd should actually do the heavy lifting 
for it. It should be done by the wireless stack in the kernel.

> > That said iwd should cope Ok with the MAC address changing behind its
> > back if it receives the RTNL notification (RTM_NEWLINK) if it isn't
> > connected.  It always updates it's copy of the address on a
> > RTM_NEWLINK so the race condition shouldn't be present I suppose.
>
> I would think so too. NM change the MAC address via RTNL only while
> scanning, early during activation, and late during deactivation.
> As the wireless daemon does/should not autoactivate the device against
> NM's wish and NM determines that the device is deactivated only after
> an event from iwd.
> Hence, there shouldn't be a race of NM interfering while being
> connected. The race is only while scanning and iwd should just cope
> with that.
>
> Alternatively/additionally, a SetMacAddress() D-Bus call would avoid
> any race and allow to leave the decision which address to user to
> somebody closer to the user.

It will not be as simple as that. You need to leave iwd with the decision making for connecting to known WiFi 
networks. It just isn’t as dumb as wpa_supplicant and from a NM perspective, you should be doing as little as 
you do with BlueZ or oFono.

This means iwd needs to be told what to do and not just an address. It doesn’t matter if it is via a D-Bus 
call or RTNL. iwd remembers known networks and will connect to them if they are in range, roam automatically 
and also switch networks if it makes sense. That means any randomization policy would have to be executed 
inside iwd and not outside. As stated above, if you want different MAC addresses per SSID, then that needs to 
be inside iwd.

So many things in the wpa_supplicant design led to “hacks” outside to add features and that really has to 
stop. It is not maintainable and the corner cases and race condition this architecture causes is just crazy.

Regards

Marcel