6

Some how while using raspi-config trying to enable wlan0 on a RPi 3, I managed to lose eth0 and instead have enxb827ebe00d07. How do I fix this?

From dmesg:

[ 4.390898] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:e0:0d:07 [ 12.252659] smsc95xx 1-1.1:1.0 enxb827ebe00d07: renamed from eth0

What is happening at time code 12.252659?

I am running buster (I know it is old):

ticktock% cat /etc/issue Raspbian GNU/Linux 10 \n \l ticktock% cat /etc/debian_version 10.13 ticktock% uname -a Linux ticktock 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux
Improve this question

3 Answers 3

Reset to default
17

You have enabled 'predictable network names' in raspi-config. Disable it and reboot.

It's probably option A2

Improve this answer
5
  • Thanks, that fixed things. Commented Feb 23 at 18:12
  • 9
    It takes a special kind of logic to use "predictable network names" for enxb827ebe00d07 instead of eth0, but then again, this is Linux. (enxb827ebe00d07 is stable. ) Commented Feb 24 at 10:13
  • 5
    Most types of predictable network device names don't even manage to be genuinely predictable, although the enx names that use mac addresses are. But the ones based on PCI slot numbers can change when unrelated devices are inserted or removed (ask me how I know...) Commented Feb 24 at 20:54
  • @GlennWillen: Yeah. I too find it's mostly worse than not having it. It's only good for laptops. Commented Feb 25 at 0:48
  • @RobertHeller: If the answer "fixed things", would you say that is an answer that should be accepted by the OP (you in this case)? Commented Feb 25 at 22:45
6

At your second line the interface is being renamed based on its physical characteristics, in this case its MAC address. This is so that it's called the same thing no matter what order your devices come up. For example, if you had multiple USB network adapters they might race to become eth0, eth1, etc and it could be different each time.

'Predictable network names' tries to resolve that by physical location (PCIe slot N) and if that fails MAC address, but it leads to long names and ones that are specific to a given board (in a different Pi it would have a different MAC address). Turning that feature off goes back to eth0, eth1, ... with the race but that's not a problem if there's only one interface as it will always win the 'race'.

Improve this answer
0

What is happening at time code 12.252659?

There are various systems used to name network interfaces. https://wiki.debian.org/NetworkInterfaceNames has a bunch of details, but to summarise.

The kernel names network interfaces based on the order in which their drivers register the network interfaces. The problem with this is that the order in which this happens can change. This became more of a problem as boot processes became less linear, and busses became more hotpluggable.

Userland software, usually udev, can later come along and rename the network interfaces. Hopefully to something more stable and predictable than what the kernel uses. However there are scenarios where such soloutions cause more problems than they solve.

Debian for years used a system known as "PERSISTENT NAMES" to take the names assigned by the kernel and stabalise them based on MAC addresses. There were a couple of issues with this scheme however.

  1. The kernel names and the renamed names overlapped with each other. This meant that sometimes extra renames were needed, e.g. if eth0 and eth1 needed to be swapped then the system would have to perform three renames. This process could suffer from race conditions.
  2. If a system was cloned, even to identical hardware, then the network interface names would change. Similarly if a network interface was replaced, even with an identical replacement, it's name would change.
  3. udev upstream wasn't really supportive of the hacks required to support overlapping "kernel" and "udev assigned" names.

Later, another scheme known as "Predictable network names" was introduced. Afaict this scheme was driven by RedHat but has now been adopted by all major linux distros. There are five schemes used to name devices. In descending order of priority.

  1. A special sceheme that only seems to be used for dell "idrac" related devices.
  2. A Scheme for "onboard" devices. Only possible if the system provides sufficient metadata about how it's PCI bus layout maps to it's physical layout and does not seem to be supported on the Pi.
  3. A scheme based on PCIe "slot numbers", again not supported on all systems.
  4. A scheme based on the "bus location" of a device, this assumes a system with a PCI bus at the top level, and potentially USB buses connected via the PCI bus. It also assumes that PCI device numbering is stable, which isn't always the case.
  5. A scheme based on the MAC address of the device.

This system works really well for big-brand PCs and servers, but it doesn't work so great on more obscure hardware. udev doesn't seem to have any information to tell is that the SMC usb hub with Ethernet is on-board and there is no PCI bus either. So "predictable net names" ends up falling back to the

As has been mentioned in the other answer you can turn on and off the "predictable net names" functionality in raspi-config.

You can also add custom rules. This can be quite useful, the SMSC USB hub with Ethernet chips seem quite rare outside of embedded linux boards, so it's quite likely that if you have for-example the onboard Ethernet and an external adapter that they will be using different chipsets.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.