After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 758301 - [RFE] stable randomized MAC address for connecting
[RFE] stable randomized MAC address for connecting
Product: NetworkManager
Classification: Platform
Component: Wi-Fi
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on: 708820
Reported: 2015-11-18 17:02 UTC by Thomas Haller
Modified: 2017-03-07 20:50 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Thomas Haller 2015-11-18 17:02:56 UTC
After bug 734081, randomization of the MAC address can be enabled or disabled.

It would be great to have a 3rd mode, which hashes the connection-uuid to create a stable randomized MAC address per connection.

Similar, to what Windows10 does (

How about: add a new mode "NM_SETTING_MAC_RANDOMIZATION_TOKEN" and a new string field "wifi.mac-address-randomization-token".

If the token of a connection is unspecified, we fallback to the connection-uuid.

With this, a user can always get the same "randomize" MAC address for certain connections. He can also create multiple connections that share the same MAC address.

This somehow overlaps with NM_SETTING_WIRELESS_CLONED_MAC_ADDRESS. Maybe there should be instead an option to randomize the cloned-mac-address?
Comment 1 Thomas Haller 2015-12-11 17:00:24 UTC
see also bug 705545 which does something related for ethernet...
Comment 2 Thomas Haller 2016-06-20 12:29:20 UTC
branch on review: th/device-inital-mac-addr-bgo708820
Comment 3 Thomas Haller 2016-06-30 06:54:12 UTC
branch merged as

Especially, now we support a stable method


which by default generates hashed MAC addresses based on the UUID, but it can be overwritten by setting connection.stable-id.

What is still missing is like windows-10 allows: to generate a new stable ID every day.
That could be implemented by supporting special stable-id, like


should start on Monday 2016-01-04, and generate an ID every 7 days. For example, today at "2016-30-6 6:30:00 (UTC)" it would generate "2016-30-27 00:00:00".

That would be possible and neat, but the full featured option is slightly complicated to get right wrt. local-time vs UTC, daylight-saving, etc.

I leave the bug open for that, th/wip/device-generate-stable-id-bgo758301 has an initial patch.
Comment 4 Thomas Haller 2017-03-07 20:50:04 UTC
commit supports dynamic values for connection.stable-id.

The following expressions are supported:


which can also be combined. See for examples.

What is still missing would be time-based expression... something like:

  ${TIME:2017-02-03,weekly} (weekly, starting with this date)
  ${TIME:2017-02-03,5d,2d}  (peridoic, starting with this day, first 5 days, then 
                             2 days, then start again).

But maybe that is totally over-engineered, and ${BOOT} is already a good start.

I am closing this as fixed. Some time-based algorithms could make sense as future RFEs.