On Wed, 2018-01-03 at 22:38 +0100, Marcel Holtmann wrote: > > 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.
Hi, 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. === > 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. best, Thomas [1] https://tails.boum.org/contribute/design/MAC_address/ [2] "wifi.scan-rand-mac-address" and "wifi.scan-generate-mac-address- mask", see man NetworkManager.conf [3] "wifi.cloned-mac-address" and "wifi.generate-mac-address-mask", see man nm-settings. [4] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/exa mples/nm-conf.d/30- anon.conf?id=b936ccd2837199d5851388122c2e44951bf20012
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
