[Bug 1574483] Re: assigns MAC-based names for devices with locally administered MAC address

Launchpad Bug Tracker 1574483 at bugs.launchpad.net
Thu May 12 01:23:41 UTC 2016

This bug was fixed in the package systemd - 229-4ubuntu5

systemd (229-4ubuntu5) xenial-proposed; urgency=medium

  * debian/udev.postinst: Don't fail if /var/log/udev is a directory.
    (LP: #1574004)
  * Set MAC based name for USB network interfaces only for universally
    administered (i. e. stable) MACs, not for locally administered (i. e.
    randomly generated) ones. Drop /lib/systemd/network/90-mac-for-usb.link
    (as link files don't currently support globs for MACAddress=) and replace
    with an udev rule in /lib/udev/rules.d/73-special-net-names.rules.
    (Closes: #812575, LP: #1574483)
  * debian/extra/init-functions.d/40-systemd: Invoke status command with
    --no-pager, to avoid blocking scripts that call an init.d script with
    "status" with an unexpected pager process. (Closes: #765175, LP: #1576409)
  * Add debian/extra/rules/70-debian-uaccess.rules: Make FIDO U2F dongles
    accessible to the user session. This avoids having to install libu2f-host0
    (which isn't discoverable at all) to make those devices work.
    (LP: #1387908)
  * On shutdown, unmount /tmp before disabling swap. (Closes: #788303)

 -- Martin Pitt <martin.pitt at ubuntu.com>  Mon, 02 May 2016 15:04:42

** Changed in: systemd (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.

  assigns MAC-based names for devices with locally administered MAC

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Yakkety:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  Originally from https://bugs.debian.org/812575: Our current
  /lib/systemd/network/90-mac-for-usb.link assigns MAC-based names to
  all USB devices. However, this is wrong and pointless for locally
  administered MAC addresses (with the second bit set to '1', see

  The old 75-persistent-net generator had this rule:

     ENV{MATCHADDR}=="?[2367abef]:*",        ENV{MATCHADDR}=""

  which ignored these devices. We need to adjust 90-mac-for-usb.link to
  do the same, and only apply to universally administered MAC addresses
  (at least until https://lists.ubuntu.com/archives/ubuntu-
  devel/2016-April/039302.html gets concluded).

  We should simply fall through the default policy of assigning location
  based names. The kernel assigned ones have no meaning whatsoever, so
  this at least provides name stability for use cases where you can rely
  on plugging the device into the same port.

  Fix: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=ec7e332

  Test case:
   - Plug in an Android phone and enable USB tethering, or a different USB device which uses locally administered MAC addresses, i. e. they change after every reboot of the device. The first byte of the MAC address must have the second bit set, i. e. the hex number matches ?[2367abef].
   - Check "ip a". With current xenial version the interface name is MAC based, like "enx12345678", and it changes after rebooting the device.
   - With this fix, the name is location based, like "enp0s1u2", and it remains stable as long as you use the same USB port.

  Regression potential: This only affects naming USB network devices. It
  should be tested that devices with universally administered MACs (i.
  e. stable, second bit is zero) keep MAC based names to avoid changing
  existing stable names. For devices with locally administered MACs (i.
  e. random ones) the name currently changes all the time anyway, so any
  /etc/network/interfaces or firewall script that refers to them is
  already broken and there cannot be further regressions there. Also,
  the updated policy is only applied after a computer reboot or
  replugging the device, the name does not change while the device is
  already plugged in.

To manage notifications about this bug go to:

More information about the foundations-bugs mailing list