Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Network interfaces suddently renamed after reboot.
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14291

PostPosted: Sat Sep 14, 2019 4:26 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Quote:
udev is preempted. The kernel activates two more network interfaces, naming them eth0 (because that is free again) and eth1 (next in sequence).
Is that the way the kernel works or does it keep track of the last name used (internally)? I don't know I've never looked at that portion of the kernel code, thus my question.
I checked the kernel code before posting my prior message. As I read it, it always uses the lowest free number, even if that number only recently became free. I base my conclusion on the implementation in net/core/dev.c:__dev_alloc_name. There is even a dance using sscanf / snprintf to keep the numbering of different groups separate, so that a wlan0 does not prevent getting an eth0.
Drag0nFly wrote:
To me, this whole "demanding" of users to redo all their configs, due to a theoretical race condition does not make sense.
The udev maintainers have made questionable decisions before. This one actually seems fairly reasonable, if a bit heavy-handed. If the feature cannot work reliably, it should not work at all. Unpredictable renaming of interfaces to the predictable names is worse than declaring the setup broken and forcing people to move to something more reliable. I would rather go through the one-time pain of migrating to a consistently functional setup than deal with an environment where there is always a small question of whether the next reboot will transpose the devices.
Drag0nFly wrote:
But again, from what eudev is actually printing to the kernel ring buffer when trying to rename the interface vs. the behavior with the old (pre-systemd) udev, it seems like the intermediate rename[n] step is omitted. Was this removed due to this apparent race condition?
I don't know why it was removed. If I were to guess, it would be because it's extra unnecessary work when your names are not racy, and it's unreliable when they are racy.
Drag0nFly wrote:
Frankly, I strongly prefer using the eth* notations and would consider version-locking (e)udev because of this.
Personally, I would just turn off renaming and use the kernel-assigned names, if I had faith that the names would always be found as intended. Your other choice is to keep using eth prefixes, but not reuse the kernel's low numbers for them. Make them ethe and ethi (external/internal), for example.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4317
Location: Dallas area

PostPosted: Sat Sep 14, 2019 4:42 pm    Post subject: Reply with quote

Hu wrote:
Drag0nFly wrote:
Frankly, I strongly prefer using the eth* notations and would consider version-locking (e)udev because of this.
Personally, I would just turn off renaming and use the kernel-assigned names, if I had faith that the names would always be found as intended. Your other choice is to keep using eth prefixes, but not reuse the kernel's low numbers for them. Make them ethe and ethi (external/internal), for example.


For me, I went to mac addr re-naming because the kernel wasn't consistent on which of my 2 8169 interfaces would be eth0 and eth1. Even when they were both driven by the same kernel module. As I stated earlier I've never had a problem since I've started using the mac addr, but it's a server that stays up 24x7, so it's bounced less that a 5-10 times a year, which cuts down on the chances of conflict.

Oh and thanks for the clarification on the kernel stuff.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Drag0nFly
n00b
n00b


Joined: 13 Sep 2019
Posts: 10

PostPosted: Sat Sep 14, 2019 5:31 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Hu wrote:
Drag0nFly wrote:
Frankly, I strongly prefer using the eth* notations and would consider version-locking (e)udev because of this.
Personally, I would just turn off renaming and use the kernel-assigned names, if I had faith that the names would always be found as intended. Your other choice is to keep using eth prefixes, but not reuse the kernel's low numbers for them. Make them ethe and ethi (external/internal), for example.


For me, I went to mac addr re-naming because the kernel wasn't consistent on which of my 2 8169 interfaces would be eth0 and eth1. Even when they were both driven by the same kernel module. As I stated earlier I've never had a problem since I've started using the mac addr, but it's a server that stays up 24x7, so it's bounced less that a 5-10 times a year, which cuts down on the chances of conflict.

Oh and thanks for the clarification on the kernel stuff.

Yep, sounds like you're in exactly the same boat as me then. I came to rely on this renaming due to the problem of having the NICs reversed. Actually, I spent a significant amount of time preparing all the other stuff on the machine - migrating firewall, mail (spam), crypto setup and numerous other packages only to find that the one thing which had never before been an issue nixed the effort completely due to the udev changes.

Well, there's always something no matter how well-prepared you think you are. ;)
Back to top
View user's profile Send private message
Drag0nFly
n00b
n00b


Joined: 13 Sep 2019
Posts: 10

PostPosted: Wed Oct 09, 2019 3:51 pm    Post subject: Reply with quote

Just to follow up on my original issue and in case any others are in the same or similar situation:

I was finally able to test this properly (the box on which I am running it is my main server, gateway and firewall – which is also running a number of other services), so any downtime is always extremely inconvenient. In any case, I've tested it in various configs and kernels now, using the same eudev version (3.2.5), compiled with '--enable-rule-generator' (USE=rule-generator) and found that the network interface renaming works in a variety of different configurations;

- Using 2x on-board RTL8168d/8111d NICs (eth0+eth1) using the r8169 driver
- Using the same on-board RTL NICs + a USB NIC in addition (using ax88179_178a module; renamed to eth1), existing on-board NIC renamed to eth2
- Using only 1x on-board Realtek NIC (second BIOS-disabled) + USB ax88179 NIC

No matter how these are switched around I have not been able to cause it to fail by running into the race condition. (This is on an Atom-powered digital signage system which boots and initializes hardware pretty fast.)

Code:

[   16.855247] r8169 0000:02:00.0: PCI->APIC IRQ transform: INT A -> IRQ 17
[   16.886636] r8169 0000:02:00.0 eth0: RTL8168d/8111d, 00:.., XID 283, IRQ 27
[   16.886644] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[   17.429855] ax88179_178a 1-4:1.0 eth1: register 'ax88179_178a' at usb-0000:00:1d.7-4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:...
[   17.429984] usbcore: registered new interface driver ax88179_178a
[   17.572977] gpio_ich gpio_ich.1.auto: GPIO from 462 to 511
[   17.584738] iTCO_vendor_support: vendor-support=0
[   17.631256] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   17.631338] iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0x0860)
[   17.634402] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   17.652220] intel_rng: FWH not detected
[   17.701952] leds_ss4200: no LED devices found
[   17.995873] r8169 0000:02:00.0 eth126: renamed from eth0
[   18.007701] udevd[649]: renamed network interface eth0 to eth126
[   18.069504] ax88179_178a 1-4:1.0 eth125: renamed from eth1
[   18.084622] udevd[654]: renamed network interface eth1 to eth125
[   18.084698] ax88179_178a 1-4:1.0 eth0: renamed from eth125
[   18.098928] udevd[654]: renamed network interface eth125 to eth0
[   18.110211] r8169 0000:02:00.0 eth1: renamed from eth126
[   18.111470] udevd[649]: renamed network interface eth126 to eth1



Thanks to @Anon-E-moose for suggesting the rule-generator flag. (I also dove into the source-trees and diffed this until I backtracked this thread so could have saved some time..;)

I would include more examples of the bootup with additional kernel-named, and subsequently eudev-renamed eth[x] devices, but syslog-ng has also decided in its wisdom *not* to log dmesg output any longer to /var/log/everything.log with the 3.6.x branch unless one is using systemd... (yay!) Now to find a fix for that as well.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum