Hi Andrew, >>> I think a valueable feature with NetworkManager + Wi-Fi + >>> wpa_supplicant is that MAC address options. >>> >>> I tried to explain how that works here: >>> https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ >>> and some ideas here: >>> https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/nm-conf.d/30-anon.conf?id=b936ccd2837199d5851388122c2e44951bf20012 >>> >>> >>> Basically, NM changes the current MAC address of the Wi-Fi device under the >>> hood. >>> But only while scanning, early when activation starts, or after >>> deactivation. >>> >>> Grep the sources for nm_device_hw_addr_set() and >>> nm_device_hw_addr_set_cloned(). >>> >>> There were/are a few issues with supplicant, where it would cope badly with >>> NM >>> externally changing the MAC address: >>> E.g. >>> https://w1.fi/cgit/hostap/commit/?id=290834df69556b903b49f2a45671cc62b44f13bb >>> http://lists.infradead.org/pipermail/hostap/2017-October/038035.html >>> >>> Also, some drivers don't support changing the MAC address at all. In the >>> past, >>> NM would fail badly in that case, nowadays, it should just log a warning >>> and otherwise work fine. >>> >>> >>> Anyway, how does iwd cope with NM externally changing the MAC address (via >>> netlink)? >>> Otherwise, could/does iwd provide a SetMacAddress() D-Bus method? >>> I don't think iwd should contain the logic for selecting a MAC address. NM >>> knows which >>> profile is active, and it knows how to generate the desired MAC address. >>> iwd could contain >>> some MAC address randomization schemes, I don't care as long as there is a >>> way for NM >>> to explicitly set the desired MAC address. >> >> I think that MAC address randomization should be done inside the kernel at >> cfg80211 level or to some level via nl80211 level from iwd. Doing that the >> hard way via RTNL and behind the back of a WiFi daemon is really a bad idea. > > 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. It > will come out in testing I'm sure, I'll try to have the mac > randomization enabled to see how well it handles the interface down-up > cycles. Ideally this too should be done through iwd device's > "Powered" property over dbus but it should still work if not. > > I'm not an iwd architect but often the answer is that if something is > a "power user" feature then it won't be supported (iwd currently > mostly wants to provide an android phone type of configurability) and > if it's a good idea for everyone then it should be always enabled and > done within iwd or the kernel. There are a few things that > wpa_supplicant and NetworkManager support that I suspect will be > considered too specialized for iwd.
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. Regards Marcel _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
