Re: How does IWD handle setting MAC address?



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]