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  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6960

PostPosted: Sun Mar 10, 2019 1:36 pm    Post subject: Reply with quote

Those predicatable names are total crap.

The "smart" idea behind it is that you could predict where your interface will be, while in real, all you could predict is the name the interface will get base on where the interface will be : and this is a total failure, because it is suppose to solve only that problem "where the interface will be".

That's what only bug users with eth* kernel naming scheme, because with multiple cards, you could predict the number of eth? entries you will get, but cannot predict who will be behind those names.
Then, you could identify who is who using their MAC address : and this time, really, the problem is solve!
You still are unable to tell "my 3com card will be eth1", it could be eth0 or eth3... but you are certain the 3com card will be either eth0, eth1, or eth2, and next to that, making a rule that target the mac of that 3com to force it to be the name you want.

That's where and what trouble users the most, because they naturally tend to want re-use eth* naming ; and this is where they fail, as kernel will only accept a renaming to another interface not already taken.
So if the "3com" card gets eth3, and user has identify it properly with a rule targetting its mac, the clash is coming because user will try to make that card eth0. A failure because eth0 is another card already.
The only proper way to solve this would be to name them in proper order ; so renaming eth0 first, in order to free eth0 namespace to futher rename eth3 into eth0 ; a non solvable issue if eth0 and eth3 need to be swap as you need a temporary interface name to hold one card to succeed.

But that's so easy to solve with different name: just making the rule renaming eth* interface to a name not use by kernel: myeth*, whatevername* ...

This to resume and shown that kernel eth* is more predictable than udev crap solution, you still cannot predict what card will be behind the eth* name, but you could predict the number of interface present, and predict then perfectly how many eth* you will get and make a rules for each interfaces and rename them into a name not using eth* name.

what udev has only done is avoiding the rename clash by using stupid names, that are base on some interface order and class the card is using ; its name is FULLY predictable as per the rules set by udev, but it won't change the fact you cannot predict where the interface will be, and so you're unable to know the name the interface will get (even you have read the udev rules to name an interface).

And you can compare the prediction result in such a scenario with 4 cards
kernel way:
* you will get 4 eth* entries, eth0-eth3
* you cannot know who will be behind each of them
udev "old way":
* you can make a rule that target all of them and change their name base on their mac to noclash_eth*
* you endup with 4 entries, name noclash_eth0 to noclash_eth2 and know who is behind each entry, because noclash_eth0 will be the card you have aim with its mac address
udev "predictable" way:
* you can "guess" that for each card, they will get their name depending on some physical entry ; ie: if it's a pci card... some other weird or critic rule or whatever, in order to properly "predict" the name, you'll have to dig udev documentation to know the rule first.
* but you still cannot predict where they are, it depends on m/b configuration or if an interface sharing many aspect with the other is there or not ; and it hit user a lot, a card name pci1whatever will appears as pci2whatever because the m/b has re-assign pci slot itself ; you could had predict that the card will end pci2whatever, but you are just unable to predict when the change will be (sometimes m/b do that just because user has disable something that seems not related at all, like onbard sound card)
* you will then randomly endup with pci1whatever or pci2whatever, and this for each cards, so 4 cryptic entries name, without really knowing who is still behind

And when it's time to actually really using the cards: user will do the natural thing : "plug the cable into the 3com card" to use it.
* With kernel base, eth0 may not be the 3com card, and user is then unable to predict that eth0 is the card to use
* With kernel and renaming, myeth0 (or whatever) WILL BE that 3com card and only this one, and user is fully able to predict if i use myeth0 and i plug the cable into the 3com -> it work!
* With udev predictable name, user endup with some cryptic name for each interface, and user still don't know where the 3com is behind them, user has to look how the card was name, say pci1whatever and predict : i will always use pci1watever because the 3com should be behind it : and this will fail once the m/b or whatever change will make that pci1whatever name change!

so what method is the more predictable?
the two problems users have with kernel were clash when renaming and properly identify what card is behind a name, udev "predictable name" solve only the clash problem, even if we accept the names are predictable (who has read the rule to fully understand how that cryptic name is made?) ; you will never be sure that the name will not change.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2870
Location: Illinois, USA

PostPosted: Sun Mar 10, 2019 2:18 pm    Post subject: Reply with quote

Leio wrote:
Tony0945 wrote:
Leio, thank you for correcting me. In the past, udev depended on systemd which was the impetus for the eudev fork.


This has been NEVER the case as of yet.
Won't continue arguing with a dev, but if udev and eudev are absolutely identical and unconnected to systemd , why do we have two?

Perhaps udev was going to become dependant on systemd or rumored to become dependent on systemd. I DO recall that at one time it was an independent program than later subsumed into systemd or scheduled or rumored to become so.
I greatly doubt that dev time was wasted in packaging and upgrading two identical packages with no difference but the name.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Sun Mar 10, 2019 3:11 pm    Post subject: Reply with quote

krinn wrote:
That's where and what trouble users the most, because they naturally tend to want re-use eth* naming ; and this is where they fail, as kernel will only accept a renaming to another interface not already taken.


I swap my eth[01]names, with a udev mac rule. Kernel doesn't care.

From dmesg

[ 1.639070] r8169 0000:03:00.0 eth0: RTL8168e/8111e at 0xffffc90000015000, a0:f3:c1:00:ba:6c, XID 0c200000 IRQ 64

[ 1.640682] r8169 0000:0a:00.0 eth1: RTL8168f/8111f at 0xffffc90000025000, 08:60:6e:87:a3:cd, XID 08000800 IRQ 65

From my rules

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:f3:c1:00:ba:6c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:60:6e:87:a3:cd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Sun Mar 10, 2019 3:17 pm    Post subject: Reply with quote

Tony0945 wrote:
Leio wrote:
Tony0945 wrote:
Leio, thank you for correcting me. In the past, udev depended on systemd which was the impetus for the eudev fork.


This has been NEVER the case as of yet.
Won't continue arguing with a dev, but if udev and eudev are absolutely identical and unconnected to systemd , why do we have two?

Perhaps udev was going to become dependant on systemd or rumored to become dependent on systemd. I DO recall that at one time it was an independent program than later subsumed into systemd or scheduled or rumored to become so.
I greatly doubt that dev time was wasted in packaging and upgrading two identical packages with no difference but the name.


Eudev isn't exactly a carbon copy of udev, but it does seem to follow it (uses udev sources with some tweaks, from what I remember)

Udev and systemd were separate, once upon a time, but systemd subsumed udev (into it's source tarball) and there were plans to make it totally a systemd product not usable outside of it (as per msgs from LP quite some time ago). When eudev took off as a viable alternative, then we didn't hear much more about tying udev to only systemd. Thus we now have two "mostly" similar products. Of course if eudev were to go away there wouldn't be any assurance that LP and co wouldn't try and make it tied to systemd only, once again. In other words the "threat" of eudev keeps udev honest, in the sense of not being a systemd only service.
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6960

PostPosted: Sun Mar 10, 2019 3:30 pm    Post subject: Reply with quote

Anon-E-moose missing source https://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6960

PostPosted: Sun Mar 10, 2019 3:35 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I swap my eth[01]names, with a udev mac rule. Kernel doesn't care.

It does, i don't think they have change that.
But the race only appears when the clash is possible.
card1 (should be rename eth1)
card2 (should be rename eth0)
if kernel see card1 first, it gave it eth0, udev rename it to eth1, no clash (no eth1 exist yet)
if kernel see card2 first, it gave it eth0, udev has no need to rename it, card1 can take eth1 without trouble too.

Still clash may appears if you lack a rule for a card. ie
kernel see card1 first with no rules -> eth0
kernel see card2 second and udev try to change it to eth0 -> boom
see, even you, if you had another network card, you will have no rule for it, and may fall into the problem if the card is seen before the two others.
not a big deal, but using another name than eth* naming would had always saved you from that.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13490

PostPosted: Sun Mar 10, 2019 5:23 pm    Post subject: Reply with quote

Tony0945 wrote:
Hu, I once had a Tyan server board that behaved unpredictably. ...
mv wrote:
I had. It is simply a question of luck and other kernel options.
OK, so we have two confirmed instances of people who were inconvenienced by the classic logic. :) I figured there had to be somebody out there.
Leio wrote:
The majority of the Linux community has decided that the pros far outweigh the cons,
What do you consider "the majority of the Linux community"?
mv wrote:
Quote:
and would have done something like "predictable interface names" right in the kernel
If this would have been possible, they would have done it. But there were long discussions, and the conclusion was that problems of this complexity should be solved in userspace.
The problem of generating automated names based on physical attributes seems simple enough. udev does it with no configuration at all, by default. Yes, persisting state so that a user-chosen name would be used would be a user-space problem, as would guaranteeing that hardware changes (such as moving to a different slot) does not change the name. Picking "predictable" default names could be done in the kernel. Could you cite these discussions?
mv wrote:
Hu wrote:
Why rename in usermode, which we know is racy
No, it is not racy. It becomes only racy if the userspace tool should have been misconfigured by attempting to use names (e.g. "eth[0-9]*") which the kernel is supposed to use.
So udev gets a chance to see the card come up with its original name, compute a new name, and assign that new name before any other user process is aware the card has a name at all? No process other than udev ever gets to see or consider using the old name in any way? My understanding was that udev was not special in this regard. It becomes aware of the new card through the same mechanism as everyone else, at the same time as everyone else sees it. If other processes see the card come up, then yes, there is a race where they could try to use the original name, then udev renames it out from under them. That race applies even if udev never picks a colliding name.
mv wrote:
Hu wrote:
when you could do a kernel patch to let userspace set a policy
There is no reason to have complicated policies in kernel, especially if many natural policies (e.g. based on MAC or other data which makes the device unique enough on your system) should be easily changeable on boot. That's exactly what tools like udev were originally developed for (long before udev became part of systemd).
The policy isn't complicated. It's an integer selector of mode (classic, MAC-based, topography based), applied to every device that gets a name. It doesn't require a call back to usermode. It doesn't track state in any way. It only chooses what goes into the initial name, using only data the kernel already has loaded. If automatic name mangling isn't sufficient for the user's needs, then a user-space program like udev would need to step in to assign explicit names.

I think this thread is drifting a bit. mgnut57: would you prefer for a moderator to pull the "predictable names" discussion out into a separate thread?
Back to top
View user's profile Send private message
mgnut57
Apprentice
Apprentice


Joined: 12 Jan 2008
Posts: 188

PostPosted: Sun Mar 10, 2019 7:04 pm    Post subject: Reply with quote

OK, this is getting weirder.

I decided to rename my interfaces to "internet0", "lan0" and "lanW0" using files in /etc/systemd/network:


Code:
# more /etc/systemd/network/*
::::::::::::::
/etc/systemd/network/90internet0.link
::::::::::::::
[Match]
MACAddress=00:1c:c0:d6:XX:XX

[Link]
Name=internet0

::::::::::::::
/etc/systemd/network/90lan0.link
::::::::::::::
[Match]
MACAddress=00:07:e9:1f:XX:XX

[Link]
Name=lan0

::::::::::::::
/etc/systemd/network/90lanW0.link
::::::::::::::
[Match]
MACAddress=00:07:e9:1f:XX:XX

[Link]
Name=lanW0


However, "internet0" becomes the renamed ip_vti0:

Code:
[   15.135066] internet0: renamed from ip_vti0
[   15.153392] systemd-udevd[2814]: Error changing net interface name 'tunl0' to 'internet0': File exists
[  134.657906] systemd-udevd[6193]: Error changing net interface name 'tun0' to 'internet0': Device or resource busy
[  134.657929] systemd-udevd[6193]: could not rename interface '8' from 'tun0' to 'internet0': Device or resource busy
[  134.679800] systemd-udevd[6193]: Process 'net.sh internet0 start' failed with exit code 1.
[  134.829273] systemd-udevd[6226]: Error changing net interface name 'tun1' to 'internet0': Device or resource busy
[  134.829312] systemd-udevd[6226]: could not rename interface '9' from 'tun1' to 'internet0': Device or resource busy
[   15.152236] internet0: renamed from sit0
[   15.183288] systemd-udevd[2830]: Error changing net interface name 'tunl0' to 'internet0': File exists
[   15.183313] systemd-udevd[2822]: Error changing net interface name 'ip_vti0' to 'internet0': File exists
[   86.582327] systemd-udevd[6545]: Error changing net interface name 'tun0' to 'internet0': File exists
[   86.582350] systemd-udevd[6545]: could not rename interface '8' from 'tun0' to 'internet0': File exists
[   86.594486] systemd-udevd[6545]: Process 'net.sh internet0 start' failed with exit code 1.
[   86.760273] systemd-udevd[6577]: Error changing net interface name 'tun1' to 'internet0': Device or resource busy
[   86.760322] systemd-udevd[6577]: could not rename interface '9' from 'tun1' to 'internet0': Device or resource busy
[   86.773674] systemd-udevd[6577]: Process 'net.sh internet0 start' failed with exit code 1.

And I now have an "eth0", which I was able to bring up:
Code:
# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 73.XXX.XXX.XXX  netmask 255.255.254.0  broadcast 255.255.255.255
        inet6 fe80::21c:c0ff:fed6:fce2  prefixlen 64  scopeid 0x20<link>
        ether 00:1c:c0:d6:XX:XX  txqueuelen 1000  (Ethernet)
        RX packets 4999  bytes 1927347 (1.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5218  bytes 1018099 (994.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


So still, I have ip_vti0 interfering with the network interfaces.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6276

PostPosted: Sat Mar 16, 2019 6:14 am    Post subject: Reply with quote

Anon-E-moose wrote:
I swap my eth[01]names, with a udev mac rule. Kernel doesn't care.

Yes, as with most races, it is highly unlikely that you get in trouble. (That's why the race was not detected/cared about by ancient udev for years). However, it is a race, and whether you get bitten by it is a matter of luck. On some systems it might happen often and on other systems practically never.
krinn wrote:
Still clash may appears if you lack a rule for a card

Not only then. The scenarios you have drawn does not describe the race:

1. kernel sees eth0 which udev is supposed to rename to eth1.
2. before udev can do the renaming, kernel announces eth1.
3. The attempt of udev to rename to eth1 fails.

Another possible scenario might be that the renaming happens between the kernel determining the new name eth1 and creating the device (I am not sure whether some preemptive model allows this; I am also not sure what the kernel does in this case; in any case, I wouldn't want to risk.)
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6276

PostPosted: Sat Mar 16, 2019 6:43 am    Post subject: Reply with quote

Hu wrote:
Could you cite these discussions?

It's the whole discussion about devfs vs. udev: Make simple heuristic rules in kernel or arbitrarily configurable rules in userspace or some half-hearted compromise.
Quote:
If other processes see the card come up, then yes, there is a race

Surprise, surprise, it is possible to shoot yourself in your foot if you want to.
If you have a process which attempts to interfere with udev's job instead of waiting for udev's announcement of the device, then you can produce a problem.
By this definition, practically every program which does task X would be racy, because you can always write a job which does some sort of opposite to task X and run it simultaneously.
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
Page 2 of 2

 
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