Deterministic names for network interfaces?

FM81 · 2018-07-04 09:38:32

Hello!

System is Devuan 2.0.0, standard installation with Network-Installer. I have an AMD64-machine, two network interfaces:
A gigabit onboard, lets call it A with DHCP and a 100M on a PCI-slot lets call it B with a static given address in a separate range of course.
If I add net.ifnames=1 to the grub-commandline nearly everything is fine. A is always 'enp3s0' and B is always 'enp2s0'.

How ever, I would prefer to have old style 'eth0' and 'eth1'; I get this if I remove the additional boot-parameter of course!
But in this case it isn't defined which is which, sometimes A = 'eth0' and B = 'eth1' an on next boot it may reversed as B = 'eth0' and A = 'eth1' (or on second or third restart only, you cannot say it, before you test it.).
Now one may think: 'Create an UDEV-rule and everything is nice.' I've created one, but it seems to be ignored completly:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:55:44:33:22:11", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

(I've also tried several variants of this.)
Is there a chance, to get the normal network-interface-names back in a stable manner?

Thank you and have a nice day ...
FM_81

Last edited by FM81 (2018-07-04 09:39:49)

fsmithred · 2018-07-04 11:18:07

Where did you put the rule?

I haven't tried ascii with two nics. Here's a discussion on the dng mailing list that might be helpful:
https://lists.dyne.org/lurker/message/2 … 1c.en.html

FM81 · 2018-07-05 04:00:22

Good morning!

I put it in

/etc/udev/rules.d/

Is this still guilty or do I have something missed in between?

Best Regards, FM_81

Last edited by FM81 (2018-07-05 04:07:26)

fsmithred · 2018-07-06 14:08:57

I think that's still the right place to put your own rules, but I don't really know much about udev rules or what goes into them. Did you try using KERNEL=="enp*" instead of KERNEL=="eth*"? (just a guess)

Another possibility is to rename the interfaces in /etc/network/interfaces. See the section on MAPPING in man interfaces. You should be able to give them any names you want.

FM81 · 2018-07-09 08:43:39

Good morning!

As UDEV-rule I've tried this:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", KERNEL=="eth*", NAME=="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:55:44:33:22:11", KERNEL=="eth*", NAME=="eth1"

and this:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", KERNEL=="enp*", NAME=="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:55:44:33:22:11", KERNEL=="enp*", NAME=="eth1"

and this:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", KERNELS=="pci000:00", NAME=="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:55:44:33:22:11", KERNELS=="pci000:00", NAME=="eth1"

and also this:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", KERNELS=="0000:03:00.0", NAME=="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:55:44:33:22:11", KERNELS=="0000:02:00.0", NAME=="eth1"

But none of them had any effect?

The mapping approach sounds good, but I have no expierience of this?
I've found many arcticles in the web, but all of them describe much more complex scenarios than a simple renaming!?
My INTERFACES-file looks as follow:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface, called "eth0" in the good old days!
auto enp3s0
iface enp3s0 inet dhcp

# The secondary network interface, called "eth1" in the good old days!
allow-hotplug enp2s0
iface enp2s0 inet static
	address 192.168.1.17
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255

Which changes has to be done, to get 'enp3s0' as 'eth0' and 'enp2s0' as 'eth1'?

Thank you and best regards, FM_81

Last edited by FM81 (2018-07-09 08:44:20)

fsmithred · 2018-07-09 12:30:53

I think this is right, but I haven't tested it. See 'man interfaces' and also look at the files in /usr/share/doc/ifupdown/examples.

Copy the get-mac-address.sh script from the examples directory into /etc/network/interfaces.d/ and make it executable. Then edit the interfaces file like this:

auto enp3s0 enp2s0
mapping enp3s0 enp2s0
  script /etc/network/interfaces.d/get-mac-address.sh
  map 00:55:44:33:22:11 eth0
  map 00:11:22:33:44:55 eth1
iface eth0 inet dhcp
iface eth1 inet static
	address 192.168.1.17
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255

UnclePa · 2018-07-09 12:35:58

One thing you might check, according to Arch's wiki, udev doesn't like upper case letters in the MAC addresses. I have 2 network cards but haven't had that problem, either because they both use the same driver or I haven't rebooted enough times for it to happen.

ralph.ronnquist · 2018-07-09 12:41:27

As far as I can tell, the first rule pair is the right one. However, it's not possible to rename an interface to an already taken name, and the problem is that the udev rules apply well after both interfaces have gained their kernel names. I.e., both names eth0 and eth1 are in use when the rules apply.

Thus, when udev wants to rename eth0 to eth1, it fails because eth1 is already taken. Then the renaming of eth1 to be eth0 also fails for the same reason.

You may however probably rely on that the interface originally named eth0 by the kernel will be processed first. You could therefore set up the rules to name the secondary interface eth2 rather than eth1. Doing so makes eth0 free for any subsequent renaming of the other interface. In that case you will have the interfaces named as eth0 and eth2 via their mac addresses.

If you insist on having eth0 and eth1 you will need a subsequent renaming to happen. That is not easily done through udev, but I think the ifrename package would be able to deal with this.

FM81 · 2018-07-09 14:56:32

@fsmithred: I've tried your suggesstion, of course I also made it executable on the new place. It gives during init two messages:

ifup: error trying to execute mapping script /etc/network/interfaces.d/get-mac-address.sh on enp3s0
ifup: error trying to execute mapping script /etc/network/interfaces.d/get-mac-address.sh on enp2s0

and ends with two unconfigured interfaes, still with their old names (enp*). If I execute the script manually (with one or two or three parameters) it simply hangs, there is no returning to the prompt?

@UnclePa: I didn't know about this fact. But all my experiments was done with lowercase (without knowing it before)!

@ralph.ronnquist: I had such an rule on Debian 6 and Debian 7 and Devuan 1.0.0. It was always seen and accepted. So I'm lost at this point and didn't understand, why well working things suddenly didn't work anymore?

Greetings, FM_81

Last edited by FM81 (2018-07-09 15:22:42)

bbatten · 2018-07-09 16:59:47

@FM81 - Just a SWAG, but are there any lines with a GOTO preceding the lines in question? (Almost embarrassed to ask.)

fsmithred · 2018-07-09 18:20:33

The example script doesn't work because it does not get the mac address correctly. The output of ifconfig changed from jessie to stretch/ascii and no longer shows HWaddr.

Edit get-mac-address.sh and change

mac=$(/sbin/ifconfig "$iface" | sed -n -e '/^.*HWaddr \([:[:xdigit:]\-]*\).*/{s//\1/;y/ABCDEF/abcdef/;p;q;}')

to

mac=$(/bin/ip link | grep -A1 "$iface" | awk '/link/ { print $2 }')

Note: If your mac addresses have any upper case letters, the above line will need more than I can give you right now.

FM81 · 2018-07-09 19:15:31

@fsmithred: If I try you last variant it starts without any error. But my interfaces are still named 'enp3s0' and 'enp2s0' ??? (No, there is nothing UPPERCASED on any place.)
May be, we should stop searching here, there seems no easy solution? Effort and benefits didn't stand in a acceptable relation for this small problem!

@bbatten: I didn't understand you answer, may be because english isn't my native language; but in none of the files is the keyword GOTO used?

Best Regards, FM_81

Last edited by FM81 (2018-07-09 19:17:48)

ralph.ronnquist · 2018-07-09 21:05:11

I don't know exactly which set up you had before or which you have now, but I do know that it works how I described.

For this, I installed a fresh Devuan ascii VM with two network interfaces, and have explored the variations. It appears to be the case, that the kernel establishes its interface naming before the udev (i.e., eudev) processing gets a chance. Therefore the first attempt to rename eth0 to eth1 fails, etc.

In my VM, I only added /etc/udev/rules.d/70-persistent-net.rules with the two rules (adapted for my mac addresses of course), and looked at the effects of the various alternatives. The set up of naming the secondary interface eth2 works fine.

This test system will of course always pass the kernel's eth0 first to udev. With physical adapters I can imagine the possibility that the kernel passes its eth1 first, in which case this solution would fail anyhow, and then you would rather need to rename both interfaces to unused names.

bbatten · 2018-07-14 19:06:18

@FM81: I mean is there a statement in the rules file that causes the section you're interested in to be skipped, like this

[19] bryan: cat /etc/udev/rules.d/28-pemicro.rules
ACTION!="add", SUBSYSTEM!="usb", GOTO="kcontrol_rules_end"

ATTR{idVendor}=="15a2", ATTR{idProduct}=="0035", MODE:="0666"
ATTR{idVendor}=="15a2", ATTR{idProduct}=="0042", MODE:="0666"
ATTR{idVendor}=="15a2", ATTR{idProduct}=="0058", MODE:="0666"
ATTR{idVendor}=="15a2", ATTR{idProduct}=="005e", MODE:="0666"
ATTR{idVendor}=="15a2", ATTR{idProduct}=="005f", MODE:="0666"
ATTR{idVendor}=="1357", MODE:="0666"

LABEL="kcontrol_rules_end"
[20] bryan:

(Don't know what pemicro is. It's just an example.) BTW, this "enp..." stuff is all news to me. Wasn't aware that "eth..." was old-style.

As another SWAG, you might try changing the KERNEL match part of your rules file lines to read 'KERNEL=="*"'

Good luck,

Last edited by bbatten (2018-07-14 19:17:47)

The officially official Devuan Forum!

#1 2018-07-04 09:38:32

Deterministic names for network interfaces?

#2 2018-07-04 11:18:07

Re: Deterministic names for network interfaces?

#3 2018-07-05 04:00:22

Re: Deterministic names for network interfaces?

#4 2018-07-06 14:08:57

Re: Deterministic names for network interfaces?

#5 2018-07-09 08:43:39

Re: Deterministic names for network interfaces?

#6 2018-07-09 12:30:53

Re: Deterministic names for network interfaces?

#7 2018-07-09 12:35:58

Re: Deterministic names for network interfaces?

#8 2018-07-09 12:41:27

Re: Deterministic names for network interfaces?

#9 2018-07-09 14:56:32

Re: Deterministic names for network interfaces?

#10 2018-07-09 16:59:47

Re: Deterministic names for network interfaces?

#11 2018-07-09 18:20:33

Re: Deterministic names for network interfaces?

#12 2018-07-09 19:15:31

Re: Deterministic names for network interfaces?

#13 2018-07-09 21:05:11

Re: Deterministic names for network interfaces?

#14 2018-07-14 19:06:18

Re: Deterministic names for network interfaces?

Board footer