GNOME Bugzilla – Bug 767420
network-manager modifes devices before udev has a chance to apply system policy
Last modified: 2016-06-09 17:53:29 UTC
Over on https://github.com/systemd/systemd/issues/3464 i reported that udev fails to randomize a device's MAC address when network-manager is running. This is presumably because network-manager brings the device up before udev has a chance to apply system policy to it. udev upstream says: > Normally NM shouldn't take possession of a device until it has > shown up in udev, and thus the MAC addresses should be in place > by the time NM sees them. So network-manager is failing to coordinate properly with udev over system policy here. (btw, the device in question is not a wireless device, so the network-manager's mac-address-randomization setting, which appears in the 802-11-wireless settings in nm-settings(5) doesn't appear to be applicable to this use case; even if it were wireless, though, i wouldn't expect to need to set mac-address-randomization in two different places to get it to work)
NetworkManager has a configuration setting ethernet.cloned-mac-address. If that a MAC address is configured, NM will apply it when activating the device. In the absence of a cloned-mac-address, NetworkManager will configure instead the permanent MAC address. Currently, you cannot use NetworkManager and expecting to externally configure the MAC address. I close this as duplicate of bug 708820, because to my understanding it's the same issue. Please reopen if you disagree about this being a duplicate. Or maybe better, if you feel you have something to add, comment on bug 708820. Thank you. There is also an work-in-progress upstream branch th/device-inital-mac-addr-bgo708820 that hopefully fixes this soon. *** This bug has been marked as a duplicate of bug 708820 ***
Thanks! I'd initially thought that network-manager was bringing the device up before udev had a chance to change its mac address, but on further testing i see that actually udev changes its mac address and n-m changes it back. I agree with your assessment that n-m is actually resetting the MAC address after udev sets it. I'm adjusting the title and adding a note to that bug to be clearer about the circumstances.