Re: How does IWD handle setting MAC address?

[Andrew Zaborowski <andrew zaborowski intel com>]

Hi,

On 3 January 2018 at 20:58, Marcel Holtmann <marcel holtmann org> wrote:
> > 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.

Best regards