You are not logged in.

#1 2013-01-20 18:19:26

jwatte
Member
Registered: 2012-06-22
Posts: 58

How to deal with renamed network interface names?

I'm running a system that does not have a GUI (it runs headless.)

A while back, I could make this auto-attach to a wireless network by enabling the netcfg service and wpa_supplicant service and setting up wpa_supplicant.conf with data for my wireless network, and /etc/networks/interface/wlan0 with data to use wpa_supplicant.

However, I've recently upgraded this system, and it re-names my "wlan0" interface to the name "wlp0s19f2u4" for reasons I don't understand.
The device is on USB hub 2 port 4, so the "f2u4" probably comes from that.
But -- if I plug in this adapter into another USB port, it will get another name. Thus, I cannot name it in /etc/network/interfaces.

So, what do I do? How do I make any plugged-in wireless network device automatically associate and connect to a network defined in wpa_supplicant.conf, without using any GUI tools?

Here's some parts of dmesg output:

[    3.148517] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    3.148836] r8169 0000:06:00.0: irq 44 for MSI/MSI-X
[    3.150248] r8169 0000:06:00.0: eth0: RTL8168evl/8111evl at 0xf943e000, 00:01:2e:47:70:76, XID 0c900800 IRQ 44
[    3.150257] r8169 0000:06:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[    3.161271] cfg80211: Calling CRDA to update world regulatory domain

[    3.280953] systemd-udevd[133]: renamed network interface eth0 to enp6s0

[    3.585143] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[    3.585850] Registered led device: rt2800usb-phy0::radio
[    3.585922] Registered led device: rt2800usb-phy0::assoc
[    3.585986] Registered led device: rt2800usb-phy0::quality
[    3.586089] usbcore: registered new interface driver rt2800usb

[    3.598160] systemd-udevd[134]: renamed network interface wlan0 to wlp0s19f2u4

[    3.999033] r8169 0000:06:00.0: enp6s0: link down
[    3.999049] r8169 0000:06:00.0: enp6s0: link down
[    3.999137] IPv6: ADDRCONF(NETDEV_UP): enp6s0: link is not ready

[    5.691096] IPv6: ADDRCONF(NETDEV_UP): wlp0s19f2u4: link is not ready

[    6.355944] r8169 0000:06:00.0: enp6s0: link up
[    6.355971] IPv6: ADDRCONF(NETDEV_CHANGE): enp6s0: link becomes ready

Also, here's the (end of) output of journalctl:

Jan 20 09:51:38 localhost kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: data=ordered
Jan 20 09:51:38 localhost systemd[1]: Mounted /boot.
Jan 20 09:51:38 localhost systemd[1]: Starting Local File Systems.
Jan 20 09:51:38 localhost systemd[1]: Reached target Local File Systems.
Jan 20 09:51:38 localhost systemd[1]: Starting Recreate Volatile Files and Directories...
Jan 20 09:51:38 localhost systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage...
Jan 20 09:51:38 localhost kernel: usb 6-3: new full-speed USB device number 4 using ohci_hcd
Jan 20 09:51:38 localhost systemd-journal[125]: Allowing system journal files to grow to 1.8G.
Jan 20 09:51:38 localhost systemd[1]: Started Trigger Flushing of Journal to Persistent Storage.
Jan 20 09:51:38 localhost systemd[1]: Started Recreate Volatile Files and Directories.
Jan 20 09:51:38 localhost systemd[1]: Starting System Initialization.
Jan 20 09:51:38 localhost systemd[1]: Reached target System Initialization.
Jan 20 09:51:38 localhost systemd[1]: Starting D-Bus System Message Bus Socket.
Jan 20 09:51:38 localhost systemd[1]: Listening on D-Bus System Message Bus Socket.
Jan 20 09:51:38 localhost systemd[1]: Starting Sockets.
Jan 20 09:51:38 localhost systemd[1]: Reached target Sockets.
Jan 20 09:51:38 localhost systemd[1]: Starting Daily Cleanup of Temporary Directories.
Jan 20 09:51:38 localhost systemd[1]: Started Daily Cleanup of Temporary Directories.
Jan 20 09:51:38 localhost systemd[1]: Starting Restore Sound Card State...
Jan 20 09:51:38 localhost dhcpcd[281]: version 5.6.4 starting
Jan 20 09:51:39 localhost kernel: [drm] fb mappable at 0xB0142000
Jan 20 09:51:39 localhost kernel: [drm] vram apper at 0xB0000000
Jan 20 09:51:39 localhost kernel: [drm] size 7680000
Jan 20 09:51:39 localhost kernel: [drm] fb depth is 24
Jan 20 09:51:39 localhost kernel: [drm]    pitch is 6400
Jan 20 09:51:39 localhost netcfg-daemon[284]: No recorded netcfg state to restore
Jan 20 09:51:39 localhost kernel: fbcon: radeondrmfb (fb0) is primary device
Jan 20 09:51:39 localhost kernel: Console: switching to colour frame buffer device 200x75
Jan 20 09:51:39 localhost kernel: fb0: radeondrmfb frame buffer device
Jan 20 09:51:39 localhost kernel: drm: registered panic notifier
Jan 20 09:51:39 localhost kernel: [drm] Initialized radeon 2.24.0 20080528 for 0000:00:01.0 on minor 0
Jan 20 09:51:39 localhost kernel: r8169 0000:06:00.0: enp6s0: link down
Jan 20 09:51:39 localhost kernel: r8169 0000:06:00.0: enp6s0: link down
Jan 20 09:51:39 localhost kernel: IPv6: ADDRCONF(NETDEV_UP): enp6s0: link is not ready
Jan 20 09:51:39 localhost kernel: usb 6-4: new low-speed USB device number 5 using ohci_hcd
Jan 20 09:51:39 localhost systemd-logind[286]: Watching system buttons on /dev/input/event2 (Power Button)
Jan 20 09:51:39 localhost systemd-logind[286]: Watching system buttons on /dev/input/event1 (Power Button)
Jan 20 09:51:39 localhost kernel: usb 6-4: device descriptor read/64, error -62
Jan 20 09:51:39 localhost kernel: usb 6-4: device descriptor read/64, error -62
Jan 20 09:51:39 localhost kernel: usb 6-4: new low-speed USB device number 6 using ohci_hcd
Jan 20 09:51:39 localhost kernel: usb 6-4: device descriptor read/64, error -62
Jan 20 09:51:40 localhost kernel: usb 6-4: device descriptor read/64, error -62
Jan 20 09:51:40 localhost kernel: usb 6-4: new low-speed USB device number 7 using ohci_hcd
Jan 20 09:51:40 localhost kernel: usb 6-4: device not accepting address 7, error -62
Jan 20 09:51:40 localhost kernel: IPv6: ADDRCONF(NETDEV_UP): wlp0s19f2u4: link is not ready
Jan 20 09:51:40 localhost dhcpcd[281]: forked to background, child pid 295
Jan 20 09:51:40 localhost systemd[1]: Started dhcpcd on all interfaces.
Jan 20 09:51:40 localhost systemd[1]: Starting Network.
Jan 20 09:51:40 localhost systemd[1]: Reached target Network.
Jan 20 09:51:40 localhost dhcpcd[295]: enp6s0: waiting for carrier
Jan 20 09:51:40 localhost dhcpcd[295]: wlp0s19f2u4: waiting for carrier
Jan 20 09:51:40 localhost dhcpcd[295]: wlp0s19f2u4: carrier acquired
Jan 20 09:51:40 localhost kernel: usb 6-4: new low-speed USB device number 8 using ohci_hcd
Jan 20 09:51:40 localhost dhcpcd[295]: wlp0s19f2u4: carrier lost
Jan 20 09:51:40 localhost dhcpcd[295]: wlp0s19f2u4: waiting for carrier
Jan 20 09:51:41 localhost kernel: usb 6-4: device not accepting address 8, error -62
Jan 20 09:51:41 localhost kernel: hub 6-0:1.0: unable to enumerate USB device on port 4
Jan 20 09:51:41 localhost kernel: usbcore: registered new interface driver usbhid
Jan 20 09:51:41 localhost kernel: usbhid: USB HID core driver
Jan 20 09:51:41 localhost kernel: input: SIGMACHIP Usb Mouse as /devices/pci0000:00/0000:00:12.0/usb6/6-2/6-2:1.0/input/input9
Jan 20 09:51:41 localhost kernel: hid-generic 0003:1C4F:0003.0001: input,hidraw0: USB HID v1.10 Mouse [SIGMACHIP Usb Mouse] on usb-0000:00:12.0-2/input0
Jan 20 09:51:41 localhost dhcpcd[295]: enp6s0: carrier acquired
Jan 20 09:51:41 localhost kernel: r8169 0000:06:00.0: enp6s0: link up
Jan 20 09:51:41 localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp6s0: link becomes ready
Jan 20 09:51:41 localhost dhcpcd[295]: enp6s0: sending IPv6 Router Solicitation
Jan 20 09:51:41 localhost dhcpcd[295]: enp6s0: sendmsg: Cannot assign requested address
Jan 20 09:51:41 localhost dhcpcd[295]: enp6s0: rebinding lease of 10.0.0.46
Jan 20 09:51:41 localhost dhcpcd[295]: enp6s0: acknowledged 10.0.0.46 from 10.0.0.1
Jan 20 09:51:41 localhost dhcpcd[295]: enp6s0: checking for 10.0.0.46
Jan 20 09:51:41 localhost kernel: usb 6-1.1: new low-speed USB device number 9 using ohci_hcd
Jan 20 09:51:41 localhost kernel: input: Logitech Logitech Gaming Keyboard as /devices/pci0000:00/0000:00:12.0/usb6/6-1/6-1.1/6-1.1:1.0/input/input10
Jan 20 09:51:41 localhost kernel: hid-generic 0003:046D:C221.0002: input,hidraw1: USB HID v1.10 Keyboard [Logitech Logitech Gaming Keyboard] on usb-0000:00:12.0-1.1/input0
Jan 20 09:51:41 localhost kernel: input: Logitech Logitech Gaming Keyboard as /devices/pci0000:00/0000:00:12.0/usb6/6-1/6-1.1/6-1.1:1.1/input/input11
Jan 20 09:51:42 localhost kernel: hid-generic 0003:046D:C221.0003: input,hiddev0,hidraw2: USB HID v1.10 Device [Logitech Logitech Gaming Keyboard] on usb-0000:00:12.0-1.1/input1
Jan 20 09:51:42 localhost kernel: usb 6-1.4: new full-speed USB device number 10 using ohci_hcd
Jan 20 09:51:42 localhost kernel: input: G15 Keyboard G15 Keyboard as /devices/pci0000:00/0000:00:12.0/usb6/6-1/6-1.4/6-1.4:1.0/input/input12
Jan 20 09:51:42 localhost kernel: hid-generic 0003:046D:C222.0004: input,hiddev0,hidraw3: USB HID v1.11 Keypad [G15 Keyboard G15 Keyboard] on usb-0000:00:12.0-1.4/input0
Jan 20 09:51:45 localhost dhcpcd[295]: enp6s0: sending IPv6 Router Solicitation
Jan 20 09:51:47 localhost dhcpcd[295]: enp6s0: leased 10.0.0.46 for 86400 seconds
Jan 20 09:51:49 localhost dhcpcd[295]: enp6s0: sending IPv6 Router Solicitation
Jan 20 09:51:53 localhost dhcpcd[295]: enp6s0: sending IPv6 Router Solicitation
Jan 20 09:51:53 localhost dhcpcd[295]: enp6s0: no IPv6 Routers available
Jan 20 09:52:05 localhost kernel: usb 6-2: USB disconnect, device number 3
Jan 20 09:52:07 localhost kernel: usb 6-2: new low-speed USB device number 11 using ohci_hcd
Jan 20 09:52:07 localhost kernel: input: SIGMACHIP Usb Mouse as /devices/pci0000:00/0000:00:12.0/usb6/6-2/6-2:1.0/input/input13
Jan 20 09:52:07 localhost kernel: hid-generic 0003:1C4F:0003.0005: input,hidraw0: USB HID v1.10 Mouse [SIGMACHIP Usb Mouse] on usb-0000:00:12.0-2/input0
Jan 20 09:52:07 localhost login[289]: pam_unix(login:session): session opened for user jwatte by LOGIN(uid=0)
Jan 20 09:52:07 localhost systemd-logind[286]: New session 1 of user jwatte.
Jan 20 09:52:07 localhost login[289]: LOGIN ON tty1 BY jwatte
Jan 20 09:53:07 localhost systemd[1]: Job sys-subsystem-net-devices-wlan0.device/start timed out.
Jan 20 09:53:07 localhost systemd[1]: Timed out waiting for device sys-subsystem-net-devices-wlan0.device.
Jan 20 09:53:07 localhost systemd[1]: Dependency failed for WPA supplicant daemon (interface-specific version).
Jan 20 09:53:07 localhost systemd[1]: Starting Multi-User.
Jan 20 09:53:07 localhost systemd[1]: Reached target Multi-User.
Jan 20 09:53:07 localhost systemd[1]: Starting Update UTMP about System Runlevel Changes...
Jan 20 09:53:07 localhost systemd[1]: Started Update UTMP about System Runlevel Changes.
Jan 20 09:53:07 localhost systemd[1]: Startup finished in 2s 359ms 845us (kernel) + 1min 30s 145ms 371us (userspace) = 1min 32s 505ms 216us.

The system is a Zotac Zbox AD11 (which uses the AMD 340 CPU/GPU/Chipset.) The USB adapter is a ra2800 based wireless interface, which works if I manually bring wpa_supplicant up for it. The specific problem I have is that I don't know how to map "any" wireless interface to the defined wpa_supplicant.conf.

Last edited by jwatte (2013-01-20 18:21:42)

Offline

#2 2013-01-20 21:04:27

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,670

Re: How to deal with renamed network interface names?

Did you reinstall the system or update? This shouldn't happen if you really updated it. Assuming you reinstalled, see https://mailman.archlinux.org/pipermail … 24223.html. You could try:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

but if you really did update the system, this file should already exist.


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#3 2013-01-20 22:42:48

jwatte
Member
Registered: 2012-06-22
Posts: 58

Re: How to deal with renamed network interface names?

I re-installed. New disk! Thanks.

Offline

#4 2013-01-21 03:43:31

jwatte
Member
Registered: 2012-06-22
Posts: 58

Re: How to deal with renamed network interface names?

cfr wrote:

Did you reinstall the system or update? This shouldn't happen if you really updated it. Assuming you reinstalled, see https://mailman.archlinux.org/pipermail … 24223.html. You could try:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

but if you really did update the system, this file should already exist.

So, I read that, and the command you suggest will disable/override the rules that rename the devices based on their hardware path.

But, that doesn't answer the question, really: How do I set up the system so that it will try to associate any and all wireless networks using the network configuration/s I have in /etc/wpa_supplicant/wpa_supplicant.conf ?

Right now, I have a netcfg config file that explicitly names wlan0, and points to that config file. However, if I were to plug in a second wlan interface (or, in the case of me actually using the default USB-path-name device names,) how do I make netcfg do the right thing?

Offline

#5 2013-01-21 06:51:10

chris_l
Member
Registered: 2010-12-01
Posts: 387

Re: How to deal with renamed network interface names?

jwatte wrote:

So, I read that, and the command you suggest will disable/override the rules that rename the devices based on their hardware path.

But, that doesn't answer the question, really: How do I set up the system so that it will try to associate any and all wireless networks using the network configuration/s I have in /etc/wpa_supplicant/wpa_supplicant.conf ?

Well, if you do that, the first wifi device is going to be called wlan0, so in theory, that would make your wifi usb to be always wlan0, no matter the usb port is connected. (in theory, I don't have an usb to test on my own)

If it actually works like that, then configure your netcfg to use wlan0 and it will work no matter the usb port used.


"open source is about choice"
No.
Open source is about opening the source code complying with this conditions, period. The ability to choose among several packages is just a nice side effect.

Offline

#6 2013-01-22 03:01:04

jwatte
Member
Registered: 2012-06-22
Posts: 58

Re: How to deal with renamed network interface names?

Well, if you do that, the first wifi device is going to be called wlan0, so in theory, that would make your wifi usb to be always wlan0, no matter the usb port is connected. (in theory, I don't have an usb to test on my own)

While that is true, it's also a non-answer! There are three reasons I don't like that answer:
1) Upstream is now using path-based naming. This means that I'll be going against upstream, and staying in the past "forever." That's like still trying to use rc.d instead of systemd, or resist Python 3, or something.
2) I might plug in a second wifi connector -- say, a 5 GHz one as well as a 2.4 GHz one. I may, actually, plug in N wifi connectors. I'd like an answer that works in general, not only in the special case.
3) Plugging in a wifi adapter and having it "just work" is a very common use case that a large number of Linux users need. This used to work fine, and made installing Linux easier for normal users. I don't want to believe that the drivers of Linux distributions would want to take a large step backwards in everyday usability, without having some substitute solution -- I'd give them more credit than that! Thus, I'd like to understand what that solution is!

Neither the mailing list thread, nor the sticky on this forum, actually talks about that, though; they are all focused on disabling the new naming behavior, which I find to be very short-sighted and ultimately futile.

Offline

#7 2013-01-22 17:12:05

chris_l
Member
Registered: 2010-12-01
Posts: 387

Re: How to deal with renamed network interface names?

jwatte wrote:

1) Upstream is now using path-based naming. This means that I'll be going against upstream, and staying in the past "forever." That's like still trying to use rc.d instead of systemd, or resist Python 3, or something.

True words. What I do is to use the new names and use the same usb port.

jwatte wrote:

2) I might plug in a second wifi connector -- say, a 5 GHz one as well as a 2.4 GHz one. I may, actually, plug in N wifi connectors. I'd like an answer that works in general, not only in the special case.
3) Plugging in a wifi adapter and having it "just work" is a very common use case that a large number of Linux users need. This used to work fine, and made installing Linux easier for normal users.

So, the system should use the new persistent names, somehow should be able to automatically use any wifi adapter present, no matter the name, and it must be possible to have a second adapter that should have its own, new persistent name, and it must not cause problems with the existing connection.

That idea is all good, is just that I don't think is implemented just yet. Maybe in the future they'll change wicd to be able to detect any wifi adaptor and use the "first one" it finds... which makes me wonder, what would happen if I boot my pc and it has 2 wifi usb plugged at the same time? which one is going to use? which one is the "first one"? Based maybe on the usb ports order?

jwatte wrote:

3) Plugging in a wifi adapter and having it "just work" is a very common use case that a large number of Linux users need. This used to work fine, and made installing Linux easier for normal users.
I don't want to believe that the drivers of Linux distributions would want to take a large step backwards in everyday usability, without having some substitute solution -- I'd give them more credit than that! Thus, I'd like to understand what that solution is!

I guess you mean what would a distro designed to average users, to avoid those problems. I think those distros wont adopt the new names until they have created a daemon or something to automagically detect if there is an adapter and use that one. If it found several, it will choose based on some arbitrary criteria or worse, ramdomly. On the last case, blog posts about "how to make ubuntu to choose the same wifi adapter" will appear.

jwatte wrote:

Neither the mailing list thread, nor the sticky on this forum, actually talks about that, though; they are all focused on disabling the new naming behavior, which I find to be very short-sighted and ultimately futile.

Agree 100%, is better to work around the new names. But with "work" I mean just using the same port, or discovering/creating a solution, instead of using an already existing one. Because I don't think there is an existing one just yet. With some luck, someone will create one and post it here.

Like I said, what I do is to use the new names and use the same usb port. If I needed to use a second adapter, I would manually configure it (I'm an arch user after all in part because I like to do that ). If that were a bother to me, I would just use the old names.

...Or if I were so interested on that, I would write an script called by a systemd unit, before wicd, that would detect which wifi adapters are connected, select one and reconfigure wicd for it. Maybe also creating pre and post connect scripts (wicd can use scripts like that) or udev rules calling an script when usb wifi adapter are connected/disconnected that will fix the wicd config and then restart the wicd service.

I don't think you will like that idea a lot, but the problem is you are assuming that an official, upstream solution exist for that, and I don't think it exist just yet.

But I could be wrong wink
If you discover the solution or develop it, post it here, please! While is true I'm not super insterested on this, it would be a nice to have it at hand.


"open source is about choice"
No.
Open source is about opening the source code complying with this conditions, period. The ability to choose among several packages is just a nice side effect.

Offline

#8 2013-01-22 18:06:10

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 949

Re: How to deal with renamed network interface names?

jwatte wrote:

Well, if you do that, the first wifi device is going to be called wlan0, so in theory, that would make your wifi usb to be always wlan0, no matter the usb port is connected. (in theory, I don't have an usb to test on my own)

While that is true, it's also a non-answer! There are three reasons I don't like that answer:
1) Upstream is now using path-based naming. This means that I'll be going against upstream, and staying in the past "forever." That's like still trying to use rc.d instead of systemd, or resist Python 3, or something.

Upstream also uses localhost as a default hostname... Really, network interfaces are yours to name and always have been. If you just realized that -- good morning smile

jwatte wrote:

2) I might plug in a second wifi connector -- say, a 5 GHz one as well as a 2.4 GHz one. I may, actually, plug in N wifi connectors. I'd like an answer that works in general, not only in the special case.

If you want to to have persistent interface names, use MAC-based udev rules. In all other cases the names will depend on the order of connections and/or on the USB bus/port.

jwatte wrote:

3) Plugging in a wifi adapter and having it "just work" is a very common use case that a large number of Linux users need. This used to work fine, and made installing Linux easier for normal users. I don't want to believe that the drivers of Linux distributions would want to take a large step backwards in everyday usability, without having some substitute solution -- I'd give them more credit than that! Thus, I'd like to understand what that solution is!

Neither the mailing list thread, nor the sticky on this forum, actually talks about that, though; they are all focused on disabling the new naming behavior, which I find to be very short-sighted and ultimately futile.

Examples? This kind of stuff never "just worked". In all cases there was a "wizard" which produced udev rules and a corresponding config generator which used proper interface names. From this perspective, nothing really changed.

To recap, there are 2 "incompatible" configurations: your networkmanager/netcfg/... and default udev ruleset. You are free to change either one. In most cases it is easier to change/avoid the latter. That's what /etc/udev/rules.d/ is for.

For instance, I have a box with 4 ethernet NICs,  2 wifi cards, and 1 USB eth adapter. Kernel-based interface names (eth? and wlan?) were strong functions of the outdoor temperature. The only way to make this mess go null was writing my own udev rules. There are multiple bridge/firewall configuration files utilizing the persistent names. Clearly, it is much simpler for me to just mask the new udev rule and keep using my own, rather than "adjusting to upstream"...

Last edited by Leonid.I (2013-01-22 18:06:59)


Arch Linux is more than just GNU/Linux -- it's an adventure

Offline

#9 2013-01-23 00:57:18

jwatte
Member
Registered: 2012-06-22
Posts: 58

Re: How to deal with renamed network interface names?

Leonid.I wrote:

For instance, I have a box with 4 ethernet NICs,  2 wifi cards, and 1 USB eth adapter. Kernel-based interface names (eth? and wlan?) were strong functions of the outdoor temperature. The only way to make this mess go null was writing my own udev rules. There are multiple bridge/firewall configuration files utilizing the persistent names. Clearly, it is much simpler for me to just mask the new udev rule and keep using my own, rather than "adjusting to upstream"...

I have similar boxes.

What I'm thinking now is that, the core of my frustration, is that upstream solved the problem in the wrong way.

A better way would be to define a point at which network interfaces are "known" -- say, after PCI, USB, and other busses are fully enumerated during boot-up, and then sort the interfaces based on the physical path, and then number them 0 .. N. At that point, the same interface will always have the same short identifier, and every Linux networking tutorial in the world won't suddenly be invalidated because what used to be "eth0" is now enp5s2 or whatever.

Another problem is that the interaction between all the components is not very clearly documented all in one place.
There's nothing that describes: "When a new network device is discovered, here are all the things/renamings/hooks/daemons/scripts that get evaluated, in order, and here's what each of them is repsonsible for."
Probably in part because there isn't actually an overall design. Different levels of that stack can do same-ish things. Think udev vs dbus vs netcfg vs ifplugd vs wpa_supplicant vs dhcpcd hook scripts.

Offline

#10 2013-01-23 02:41:23

chris_l
Member
Registered: 2010-12-01
Posts: 387

Re: How to deal with renamed network interface names?

jwatte wrote:

A better way would be to define a point at which network interfaces are "known" -- say, after PCI, USB, and other busses are fully enumerated during boot-up, and then sort the interfaces based on the physical path, and then number them 0 .. N. At that point, the same interface will always have the same short identifier, and every Linux networking tutorial in the world won't suddenly be invalidated because what used to be "eth0" is now enp5s2 or whatever.

So my only ethernet card would not be eth0, but it could be eth2, because is on pci slot number 2.

Now, those tutorials tend to assume the computers that only have one ethernet card, have that card named "eth0", so they still would be a bit invalidated (some newbies would be copy-pasting a command like "ifconfig eth0" from some tutorial and wondering why it does not work).

Anyway... but what if I also have an ethernet usb key, on usb port 2? Oh, I guess they could add a letter "u" to usb ports and a "p" to pci slots. So, instead of eth0, it would be called ethp2 if is on pci slot number 2, and ethu2 if is on usb port 2.

...I don't see having to deal with names like ethp2 much different than dealing with enp5s2. Even if it was just eth2, it would still not be eth0 always. Some people following old tutorials will wonder why on one pc is eth2, in other is eth5 and on a third one is eth0.

Also, lot of old tutorials got invalidated because of systemd. So what? things change.

jwatte wrote:

Another problem is that the interaction between all the components is not very clearly documented all in one place.
There's nothing that describes: "When a new network device is discovered, here are all the things/renamings/hooks/daemons/scripts that get evaluated, in order, and here's what each of them is repsonsible for."

Maybe here: http://www.freedesktop.org/wiki/Softwar … rfaceNames
From the website:

  1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)

  2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)

  3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)

  4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)

  5. Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

This combined policy is only applied as last resort. That means, if the system has biosdevname installed, it will take precedence. If the user has added udev rules which change the name of the kernel devices these will take precedence too. Also, any distribution specific naming schemes generally take precedence.

Check the link for more info.

jwatte wrote:

What I'm thinking now is that, the core of my frustration, is that upstream solved the problem in the wrong way.

Hmm, complain to upstream then. hmm This thread is starting to look more like a rant, than actually looking for a solution.
The thread was about how to plug a wifi usb on different ports and have it working no matter the port. Well, the first solution about disabling the persistent names allows that.


"open source is about choice"
No.
Open source is about opening the source code complying with this conditions, period. The ability to choose among several packages is just a nice side effect.

Offline

#11 2013-01-23 17:24:00

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 949

Re: How to deal with renamed network interface names?

jwatte wrote:

I have similar boxes.

What I'm thinking now is that, the core of my frustration, is that upstream solved the problem in the wrong way.

A better way would be to define a point at which network interfaces are "known" -- say, after PCI, USB, and other busses are fully enumerated during boot-up, and then sort the interfaces based on the physical path, and then number them 0 .. N. At that point, the same interface will always have the same short identifier, and every Linux networking tutorial in the world won't suddenly be invalidated because what used to be "eth0" is now enp5s2 or whatever.

Yes, that's what udev rules are for. For example, if you write a custom rule, in syslog you'll see messages like "renamed eth0 to abcde". I don't think that anyone should care about old tutorials scattered around the web.

jwatte wrote:

Another problem is that the interaction between all the components is not very clearly documented all in one place.
There's nothing that describes: "When a new network device is discovered, here are all the things/renamings/hooks/daemons/scripts that get evaluated, in order, and here's what each of them is repsonsible for."
Probably in part because there isn't actually an overall design. Different levels of that stack can do same-ish things. Think udev vs dbus vs netcfg vs ifplugd vs wpa_supplicant vs dhcpcd hook scripts.

Hmm, "man udev"? Somehow people seem to misuse udev a lot. It is for dealing with low-level hardware only. Therefore, the path is clear: udev applies it s rules -- interfaces/devices become available -- netcfg/NM uses them. Ifplugd/dhcpcd are called by the network management software, and dbus is a mere way of communicating between server backend and client frontend if necessary (NM daemon and applet, while netcfg doesn't have a frontend at all)... What is so complicated here?


Arch Linux is more than just GNU/Linux -- it's an adventure

Offline

Board footer

Powered by FluxBB