Ubuntu 17.04: how to rename a USB network interface based on Path? (NOT based on MAC)

Question

No, this ain't a duplicate of Why doesn't my Wi-Fi adapter show up as wlan0 in 16.04?, as this explains how to restore eth0 naming, but not how to individually name a specific interface.

I don't want to assign based on MAC match. All I need is to assign name based on the USB path.

When I plug in an USB network adapter, on Ubuntu 17.04 it gets assigned a network interface name based on its MAC, such as encx000000000000. Now I would like to rename it to something more telling, based on its ID_PATH=pci-000:02:03.0-usb-0:1:1.0. In particular, I don't want to match based on MAC address. The rationale is that after interface replacement all would break down, but if someone simply replaces network interface hardware so that the new hardware is in the same place as the old one, the system will tuck on without needing IT and reconfiguration support.

So I created a file /etc/systemd/network/50-my-island.link:

[Match]
Path=pci-000:02:03.0-usb-0:1:1.0
[Link]
Name=island0

Unfortunately, the name is never assigned. Using udevadm info I can see that there is ID_NET_NAME=island0 set, but it does not apply. Trying NamePolicy= or NamePolicy=name under the [Link] section doesn't help either.

I'm lost! How can I assign my name in the .link file to my USB network adapter? Is this possible at all without resorting to some udev rule? Why then having .link files at all when they don't seem to work in my case? Where did I make an error?

Solution 1

So I finally figured out myself what really is happening.

Alas, the problem I'm seeing that renaming USB-based network interfaces doesn't work is actually caused by the udev rule /lib/udev/rules.d/73-usb-net-by-mac.rules on Ubuntu/Debian (and thus also Raspbian). The culprit in it is here:

ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", NAME=="", \
  ATTR{address}=="?[014589cd]:*", \
  TEST!="/etc/udev/rules.d/80-net-setup-link.rules", \
  TEST!="/etc/systemd/network/99-default.link", \
    IMPORT{builtin}="net_id", NAME="$env{ID_NET_NAME_MAC}"

Notice how this specific rule checks for /etc/udev/rules.d/80-net-setup-link.rules to be present; if it's not, then NAME will be set to a MAC48-based name, and the later default install rule /lib/udev/rules.d/80-net-setup-link.rules will never get a chance to assign NAME. Now that's sad. Again.

In order to enable the ability to assign user-defined names to USB network interfaces, we need to have /etc/udev/rules.d/80-net-setup-link.rules, as this is the rule set 73-usb-net-by-mac.rules checks against before assigning NAME.

This means that simply linking from /etc/udev/rules.d/80-net-setup-link.rules to /lib/udev/rules.d/80-net-setup-link.rules is needed in order to avoid that user-assigned network interface names get ignored any longer.

sudo ln -s /lib/udev/rules.d/80-net-setup-link.rules /etc/udev/rules.d/80-net-setup-link.rules

Reboot. Done.

Please note that a side-effect of the way 73-usb-net-by-mac.rules is set up, this causes all USB-based network interfaces to assume "old" naming eth0, et cetera, unless explicitly named in a .link file.

I don't know why the rules have been written as they are, as it would be fine to have MAC-based naming for all USB network adapters not explicitly named. On a second thought ... no, using MAC48-based names does not make any sense, unless you happen to label all your USB network dongles and constantly swap them around; but maybe the MAC-based names are used with docking stations, where it actually would make sense...?

Solution 2

As per this thread and especially this paragraph:

Custom net interface naming ... The name of the rules file needs to have a prefix smaller than "80" so that it runs before /lib/udev/rules.d/80-net-setup-link.rules, and should have a prefix bigger than "75" so that it runs after 75-net-description.rules and thus you can use matches on ID_VENDOR and similar properties. ...

I did create this file : /etc/udev/rules.d/76-netnames.rules

with this content

# USB device by path
# get ID_PATH if not present yet
ENV{ID_PATH}=="", IMPORT{builtin}="path_id"
SUBSYSTEM=="net", ACTION=="add", ENV{ID_PATH}=="*-usb-0:1.*", NAME="eth%n"

it is working fine, without the workaround you provided.

I created this file in a debian preseed.cfg to set my target network configuration in a Debian fully automated installation.
Doing this on an Intel NUC, my internal NIC is now named eno1 by Debian 9.5 (stretch)

Comments

[You'reAGitForNotUsingGit]

Possible duplicate of Why doesn't my Wi-Fi adapter show up as wlan0 in 16.04?

[TheDiveO]

sudo touch /dev/null /etc/udev/rules.d/80-net-setup-link.rules now causes the USB network interface to become eth0. Slightly better, but still wrong!

[TheDiveO]

Did anyone read my question carefully? I asked how to rename an interface based on its path, not it's MAC. All dupes here link to restoring old naming or assigning by MAC. Is this so difficult to understand?

[Fabby]

Wow! Excellent first answer! Welcome to Ask Ubuntu! ;-)

[TheDiveO]

how is this supposed to work when there is lib/udev/rules.d/73-usb-net-by-mac.rules where 73<75?

[TheDiveO]

This is basically an alternate solution which requires users to configure udev(!) rules. My original question was to use the systemd-based link configuration mechanism and trying to avoid fiddling with udev rules. The rationale for going with systemd is to keep configurations confined to a single mechanism which might be easier to others to understand, more so as network configuration cannot and does not belong to udev.

[Brice Miramont]

TheDiveO, the rules is applied between 75 and 80 and it does work. I undestand your point. Using udev is pretty common though (I used it for HDD device ownership for Oracle DB on Linux/Unix). A bit geeky but Debian stretch quite changed the naming rules of the nic cards. I used this workaround first :

[Brice Miramont]

Put "net.ifnames=0" into the kernel command line (e. g. in /etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT, then run "update-grub") but I changed it back after reading that the order of the interfaces was not stable.