USB NICs get too long name for ifupdown aliases or bridge names

[Andres Rodriguez]

I have a USB NIC that is connected to my denial system. I tried to create an alias, and after reboot, it wasn't created. When I manually try to bring it up I have the error.

/e/n/i:

auto enx000ec688b79f
iface enx000ec688b79f inet static
        address 10.90.90.1
        netmask 255.255.255.0

auto enx000ec688b79f:1
iface enx000ec688b79f:1 inet static
        address 192.168.100.1
        netmask 255.255.255.0

ubuntu@maas00:~$ sudo ifup enx000ec688b79f
ubuntu@maas00:~$ sudo ifup enx000ec688b79f:1
RTNETLINK answers: Numerical result out of range
Failed to bring up enx000ec688b79f:1.

[Mathieu Trudel-Lapierre (cyphermox)]

Looks like at first glance ifupdown is confused by this naming format together with the subif. I'll try to reproduce here, I do happen to have a USB ethernet dongle that should show this problem.

[Mathieu Trudel-Lapierre (cyphermox)]

ifupdown handles the passed names correctly, but it looks like iproute2 is very unhappy about something in these long names like "enx000be608397d:1"; when setting the label for the address. Since the label must match the device and it otherwise works with "eth1:1", I'll looking into the iproute2 code now.

[Mathieu Trudel-Lapierre (cyphermox)]

This isn't a simple problem at all.

The new naming scheme from systemd makes it so that these specific devices (USB dongles) get their MAC address encoded in the device name, which brings it up to a length of 15 characters + \0; so 16 bytes. This happens to also be the size limit for interface names (set as IFNAMSIZ to 16). Adding more characters to the end of this string makes it too long to be allowed by {libnl3, kernel, iproute2}. This is because while we're not strictly dealing with interface names here, we're dealing with a label which is bound by the same sized buffer (limited to IFNAMSIZ size).

There are a few possible avenues for a solution:
 - Rename the address yourself to something smaller. This should be possible using udev rules.
 - Fix systemd to pick a different naming method.
 - Fix ip addr to better deal with address labels, which may mean dropping some backward compatibility (more below)
 - Increasing the buffer size for address labels (which means changes in the kernel, libnl, iproute2 at the very least, and probably many more userland utilities).

For iproute2:
       label LABEL
              Each address may be tagged with a label string. In order to preserve compatibility with Linux-2.0 net aliases, this string must coincide with the name of the device
              or must be prefixed with the device name followed by colon.
It may be possible to strip out anything before the colon if a label is passed in that format to hand to the netlink layer a shorter label, but I haven't looked more closely at what such a change might impact.

[Mathieu Trudel-Lapierre (cyphermox)]

I pinged pitti on IRC earlier today, and just subscribed him for guidance on whether this can be fixed in systemd; which seems to be the least intrusive way to handle this (aside from expecting users to know about this limitation and renaming interfaces themselves).

[Martin Pitt (pitti)]

I actually re-started the discussion about that (about the third time) a few days ago on https://lists.ubuntu.com/archives/ubuntu-devel/2016-April/039302.html . This is actually another point in favor of moving to location based USB names by default.

@Andres: For the time being, please see /usr/share/doc/udev/README.Debian.gz for an overview how to configure the naming.

[Martin Pitt (pitti)]

This isn't iproute's fault IMHO. There hasn't been much response to the thread so far, and it's getting tight.

Reassigning to udev as that's where USB NIC names are set.

[Mathieu Trudel-Lapierre (cyphermox)]

Indeed it's not iproute's fault, it's just an unforseen consequence of using a long string like a MAC to name the device. Perhaps reducing it by half and using just the second half of the MAC might be good? The chance of collisions would remain pretty low.

[Mike Pontillo (mpontillo)]

This is also an issue for VLAN interfaces. To support VLANs, 10 characters should be the max. (16 - 1 [for \0], -1 [.], -4 [vid])

Throw in VLANs plus aliases, and, well, I guess we ought to use shorter names, such as (I don't know) "eth0". ;-)

[Dimiter Naydenov (dimitern)]

Additionally, Juju creates bridges on top of both physical and VLAN interfaces to allow for the same level of addressability for containers as regular machines. The bridges currently use the "br-" prefix and the underlying device name, which if it happens to be "enxxaabbccddeef0.1234" already, obviously won't work. So the length limit on interface names can be even lower than what Mike suggested.

[Andreas Hasenack (ahasenack)]

I just hit this deploying a MAAS2 xenial node that has a usb nic:

# ifup br-enx0023552c6029

Waiting for br-enx0023552c6029 to get ready (MAXWAIT is 76 seconds).
RTNETLINK answers: Numerical result out of range
Failed to bring up br-enx0023552c6029.

It went far enough to create the bridge, but with a truncated name and no IP:
# brctl show
(...)
br-enx0023552c6 8000.0023552c6029 no enx0023552c6029

[Andreas Hasenack (ahasenack)]

I renamed the NIC in the MAAS node page to enx0 to workaround this issue.

[Andreas Hasenack (ahasenack)]

@andres that's a cool feature, btw :)

[David A. Desrosiers (setuid)]

Doesn't adding "net.ifnames=0 biosdevname=0" to your kernel boot line fix this for you? It will stop udev from creating the longer-than-desired names.

[Andreas Hasenack (ahasenack)]

Maybe, but that will affect all nics in all nodes.

[Kalle Tuulos (kalle-tuulos)]

This feature worked well in my earlier installation (16.04LTS), but when I re-installed the system yesterday, adding an alias to my USB network adapter didn't work any more.

---8<---8<---
$ sudo ifup enx000000000016:0
RTNETLINK answers: Numerical result out of range
Failed to bring up enx000000000016:0.
---8<---8<---

The earlier installation was made using Xubuntu 16.04 installation media and this time I installed the system using Ubuntu 16.04.01 mini iso media, if this makes any difference.

[Michael Crawford (michael-crawford)]

I just lost 3 days to this issue before I realized what was happening. I realize this is an edge case, and understand the issues with fixing this, but at least some type of better error messages would have helped prevent that waste of time.

I was trying to setup a host to run docker with macvlan networks mapped to vlan interfaces on a pair of USB ethernet adapters connected to a BRIX used for testing. Couldn't get a bond on the pair to work, couldn't figure out why, then tried for just VLAN interfaces, and that didn't work either. Thought I was losing it, didn't seem that hard.

Not sure how I figured it out, but realized if I switched back to using eth1, eth2 for the USB ethernet devices, using "net.ifnames=0 biosdevname=0" boot options + old-style mac-address rules to map, I could get everything to work. But, wasn't happy with the workaround, as I'd prefer to use the new predictable names.

I like the idea of using last 6 digits of Mac address. I thought of doing this:
sudo ln -s /dev/null /etc/udev/rules.d/73-usb-net-by-mac.rules
to go back to slot names, but if I plug into different ports, names change, so no.

Perhaps some different prefix other than enx to avoid confusion, usb123456 anyone?

[Mathieu Trudel-Lapierre (cyphermox)]

Milestoning, since we should try to not drop the ball on this bug; I will need to revisit the mailing list thread and how exactly we do the naming for these devices.

[Peter Ziobrzynski (pzi-j)]

Good that we have a workaround - "net.ifnames=0 biosdevname=0". Still, I think we need to reevaluate the importance level of "medium" - this is toxic.

[Mathieu Trudel-Lapierre (cyphermox)]

Moving to "ubuntu-17.05" (in other words, "just past zesty release"). I think this still needs to be addressed and I'm sorry it hasn't been fixed yet. I'll revive the discussion on this subject and look at the already proposed solutions.

Seems like we don't need vastly new technology to properly handle VLANs, bridges, aliases at least in the typical situations; especially given that there *are* workarounds.

[Kalle Tuulos (kalle-tuulos)]

Just an update - this problem still exists in Ubuntu 16.04.3 LTS.

In case someone gets to this page due to this problem, there is a workaround. Downside on this workaround is, that all network interface names are then changed to eth0, eth1, eth2 etc, so one must change settings on the /etc/network/interfaces -file so, that they work also after this change.

Steps:
1) Update /etc/default/grub as follows:
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

2) Update GRUB:
sudo update-grub

3) If necessary, modify /etc/network/interfaces, specially if you have static IP addresses

4) Reboot the computer.

[Sebastian Mangelsen (wirseefahrer)]

Hi,

we're running into the same problem and wonder whether we could use a sub-string of the MAC address instead. Does the UDEV library support something like $env{MAC_ADDR:6}?

[Zhu Shengli (akarei)]

I don't understand why this is a won't fix bug.

If users pick a long NIC name by themselves, then it's users' responsibility to fix it. But apparently this is not the case, it's an unexpected behavior caused by internal conflicts of different linux components.