You can read more about the various options here.

I don't think it's safe to use a totally random MAC address since that's going to break many users, but I expect using the "stable" setting should be safe since it will use a consistent fake MAC address per network. Not sure why this is not default. Perhaps the NetworkManager developers could clue us in.

Hi @thaller, can I ask you to comment here please?

Sounds like a reasonable thing to do (not "random", but the "stable" mechanism). I think that is also what my Android does.

Fedora could install a snippet like /usr/lib/NetworkManager/conf.d/35-wifi-mac-addr.conf with

[connection.35-wifi-mac-addr]
wifi.cloned-mac-address=stable

that probably should take care of it (where the user still can override it per-profile). You can use that for testing the behavior (if you do it manually, put the file to /etc/NetworkManager/conf.d instead).

The only ugliness is that maybe a clean installation of Fedora should not ship any configuration snippets and default behavior should be built-in. On the other hand, changing the default in NetworkManager (either upstream or in Fedora only) makes the documentation about the behavior more confusing and is maybe an undesired change in behavior. After all, the "preserve" default was chosen intentionally, so that users could run macchanger (which probably isn't a great idea if NetworkManager can do it already).

I think the default value for "wifi.cloned-mac-address" should be made a compile time default (between "preserve" and "stable") so that a distros can choose. And the documentation needs adjustment (documenting that the default depends on the build options). We do that at other places already.

in 35-wifi-mac-addr.conf we could also contain:

[connection.35-wifi-mac-addr]
match-device=type:wifi
wifi.cloned-mac-address=stable
connection.stable-id=${CONNECTION}/${BOOT}

to get a different MAC on each boot. But it stays unchanged on reconnect (to the same profile). Here too, the built-in default for stable-id could be adjusted for Wi-Fi profiles without requiring a configuration snippet.

Not sure why this is not default. Perhaps the NetworkManager developers could clue us in.

A changing MAC address can be annoying. For example, you might need to re-authenticate on the captive portal or at home, you might get different MAC addresses. The "stable" method avoid most of these problems (compared to "random").

Another reason is that historically this wasn't done, and we are reluctant in NetworkManager to change things where a package-update would change your setup. But obviously we do that sometimes.

The main reason is probably as always: nobody cared enough to push for the change and to contribute the work. Thanks for raising the issue. Patch welcome :)

The connection defaults are inflexible (no D-Bus api to set/query them) and dangerous (it changes behavior of existing connection profiles).

What should happen instead is that whatever requests creation of the connection profiles (GNOME Shell) should just send them in with the desired properties. It could also be made configurable
viae Control Center or Tweaks.

i find it is normal in android and android does this from android 10 hopefully
it sets randomized mac as default

I don't think it should stop us from doing this, but note that this would affect upgrading users that have already configured a DHCP server / router to give their Fedora system a stable IP using the existing MAC address. A release note entry seems sufficient to me.

Seems we have consensus that the default behavior should be stable randomized MAC addresses, but two competing proposals for how to implement it: change default in NetworkManager, or change default in gnome-control-center?

I'm kinda more inclined to change the default in NetworkManager rather than implement custom policy in gnome-control-center. Yes it could break some users when upgrading, but this should be uncommon, and a release note entry seems sufficient to me. If we do it via the change proposal process, that will generate more publicity and heads-up as well.

Hi @thaller @lkundrak, could you please discuss between yourselves and agree on how best to implement this? Either:

• Change the underlying NetworkManager defaults, or
• Change gnome-control-center and also nmcli defaults (let's keep them consistent)

Seems we have consensus that the default behavior should be stable randomized MAC addresses, but two competing proposals for how to implement it: change default in NetworkManager, or change default in gnome-control-center?

How do you define consensus?
Why do we always need to change a running system? Let it on preserve and let people set it to whatever they want if there is options that they want to make use of. It's literally one click away.

Please don't just randomly mess with defaults - it will break people's systems. Network systems may be configured to work on preserved MAC addresses.

For example, users will upgrade and receive new mac addresses without even noticing - after that they are surprised why authentication or DHCP isn't working as expected.

If we don't have to default to every new feature just because it exists. It's much better to turn this feature on (say a knob in Gnome Tweaks) but not mess with existing systems.

I'd rather see this changed in NetworkManager itself. It's a good default across the board, and users who need it to be different can change it on a per-connection basis in nm-connection-editor/plasma-nm/nm-applet/etc.

Alternatively, if we want to do UX work in GNOME, then prompting for whether it's a public or private network before connecting could let us set the correct NetworkManager setting for the connection.

Alternatively, if we want to do UX work in GNOME, then prompting for whether it's a public or private network before connecting could let us set the correct NetworkManager setting for the connection.

In the past, there has been resistance to asking that question, with the concern that most users do not really know what that means nor the implications. I think we could find some wording that would be reasonable, though (and think we should set up different firewall rules based on that, too...)

It is unreasonable to say that users don't understand it unless you're unwilling to explain in the prompt. Windows brings up a dialog for categorizing a network connection and describes what each type of connection means and the consequences of it. It's lazy to say we won't do it because users won't understand. Nobody understands anything unless you teach them.

Hi @thaller @lkundrak, could you please respond here again? Goal is to default to stable randomized MAC address for new connections. Connections created by nmcli, gnome-control-center, and gnome-shell should all receive this change. (And ideally, we wouldn't touch any connection that already exists. Is that possible?)

One more ping for @thaller and @lkundrak.

If no response, let's just patch the defaults in NetworkManager. That seems better than papering over this in a bunch of different places (gnome-control-center, nmcli, nm-connection-editor).

I expressed my personal opinion how to solve this (here). @lkundrak and @bengal disagree with that solution (which is totally fine!). In my opinion, other solutions are not suitable, so I am not personally pursuing other solutions. Maybe @lkundrak and @bengal could elaborate on how this should be resolved instead and lay out a plan to do it?

here would be a patch for what I would suggest (untested).

here would be a patch for what I would suggest (untested).

Workstation WG discussed this today and like this approach. In particular, we don't like the idea of gnome-control-center, nmcli, and nm-connection-editor all making separate decisions about MAC address randomization.

But this is a significant change, and we think it should go through the change proposal process and appear in the release notes. @thaller, do you want to collaborate on drafting a change proposal for FESCo? I'm able to help with this.

@thaller are you able to implement this?

Hi, Workstation WG has agreed that MAC IDs should be randomized and it should be implemented in the manner proposed by @thaller. However, we can't force anybody to do work and nobody is signed up to implement this. @thaller has already written a patch (two comments up) that could easily be turned into a merge request, so no coding work is required. The rest of the work would be drafting a change proposal and shepherding the change through the approval process.

I'm going to close this as "fixed" in the sense that Workstation WG has rendered a decision and we don't need to track this as an open issue anymore.

It seems this won't actually be fixed anytime soon because nobody is planning to implement it. Help welcome.

Some progress is happening here.

upstream changes are completed for upcoming 1.46 release (1.45.8+):

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1789

See also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/ea8dbd7a6d0f29a35f573f12630fbad46f520dc0

This will hit Fedora 40 (Fedora 40 anyway gets frequent rebases to upstream main branch). A system-wide Fedora-Change will need to be written (TODO+WIP).

• https://docs.fedoraproject.org/en-US/program_management/changes_policy/
• https://fedoraproject.org/wiki/Releases/40/ChangeSet

Yay, thank you!