Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
predictable network interface names
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Tue Jun 18, 2013 12:08 pm    Post subject: Reply with quote

broken_chaos wrote:
I mean keeping the old rule generator exactly as it was, meaning the rules would be generated for each new network device that maps them, via MAC address, to a persistent device name,

I misunderstood you then. Yes, this is not so easy to achieve. But is this really something that somebody wants? I.e. if you have inserted into a machine 10 wifi sticks then the next will be wn11 and stored forever? In practice, you will want to store permanently only the MACs of those devices which really are permanent in the machine while the rest should be done with some reasonable heuristics: So in practice you will probably want to fill fixed rules for your fixed devices and the remainder be handled automatically, don't you? IMHO this is exactly what the current default does. If you make no configuration, all is treated by a (not perfect) heuristics, and if you want something permanently you configure it manually to be so.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2838

PostPosted: Tue Jun 18, 2013 12:37 pm    Post subject: Reply with quote

mv wrote:
Aiken wrote:
The eth0 eth1 machines come up in the same order every time.

Then you had good luck. It is likely that the order remains, but you cannot rely on it. If you just rely on the automatic kernel order my experience is that the order differs in about 1 of 20 boots, but this number depends very much on what you have built as modules (even completly unrelated modules!) your disk layout etc. If you risk the race condition with udev it is even much less likely, but still it may happen. It is not acceptable to have such a risk e.g. on a machine which is hundred miles away.


I have two dual-homed machines, and they have always come up in the same order. There was one time, probably 10 years ago, when that order switched and I had to adjust the configuration. I presume it was due to some change in the way the kernel enumerated things. But prior to that change every boot was consistent, and after that change every boot has been consistent.

Personally I think the pci/usb-based enumeration is a complete mess, and the ONLY way to do this would have been with the MAC. Non-networking changes to the machine can change the pci/usb enumeration. Obviously changing network hardware will change the MAC, and will change MAC-based naming, but when you're changing network hardware it's a reasonable expectation that you're going to have to fiddle with configuration. Further, I could see for pci/pcie based network hardware it would be reasonable to see that on a new boot one piece of hardware disappeared and another appeared, so reuse the name. I wouldn't suggest that for usb network hardware.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
miket
Apprentice
Apprentice


Joined: 28 Apr 2007
Posts: 248
Location: Gainesville, FL, USA

PostPosted: Tue Jun 18, 2013 1:16 pm    Post subject: Reply with quote

broken_chaos wrote:
depontius wrote:
Could someone please explain the naming race condition to me.

If a new network device was activated while the rename was happening, it could fail. If udev was trying to rename eth0 to eth1 and a new ethernet device was plugged in just prior to doing this, the kernel will name it eth1 and udev's rename would fail. This would sometimes cause weird results like having eth0_rename and eth0 at the end of boot. It wasn't extremely common to have problems, but it definitely did happen (I saw it at least once about five years ago).

Basically, there's no way to prevent this from being able to happen (in some form) while using the same namespace as the kernel (eth/wlan/etc.), so there was a need to move to a new namespace. The entirely redesigned name scheme (rather than just a new namespace) was the part that was tacked on in what probably seemed like a good idea to someone at some time.

I've been looking through the kernel source, and I can tell you that, yes, there's a way to keep the race from happening. Even for people not starting udev or systemd in the initrd--or even for people without an initrd at all--a race could occur for network interfaces whose drivers are loaded from kernel modules. This is because udev flails around loading kernel modules and renaming interfaces at the same stage of processing. If you build your kernels with the network drivers in-kernel (as most Gentoo people do), the kernel does all of its boot-time device enumeration before init runs. No wonder I've never had problems with races in network-interface naming!

Hmm. Yet another reason to prefer built-in drivers to drivers in loadable modules.

(The order of probing, by the way, is probably not what you'd expect. The drivers/net/Space.c file has a bunch of #ifdef blocks that are expanded according to the configuration settings. The order that the developers wrote these groups to the file determines the order of the probing. Though a given driver might enumerate devices with similar hardware in some slot-defined order, when it comes to devices with dissimilar drivers, the ordering has nothing to do with bus order, BIOS settings, or anything like that.)


This means that if we want to beat this race issue while being able to keep using names that match the regex ^(eth|wlan)\d+$, the way is to keep the kernel from assigning names that look like that when it loads a module. Doing something as simple as appending the letter k to these kernel-generated names would do the trick. The kernel code that handles module initialization is fairly byzantine, though. It seems that the register_netdevice() function affords the best opportunity to set up these names, but I couldn't be sure without being clear on how the initialization works. I'm still working through it.

One thing I've come to realize is the reason these bus-based interface names exist in new udev. They (Sievers and Poettering) evidently wanted an unambiguous way to assign a name without depending on any kind of counter (and therefore a semaphore to protect the counter). Because only one adapter can be plugged into a bus slot any any one time, that hardware address is useful as the basis for the default device name. At this point the most honest and beneficial thing to do would have been to say is "well folks, you need to write udev rules now so that you can get to meaningful and predictable names like 'wan0' or 'net1' and not use the useless default names like enp0s3." Ah, no. They go Orwellian on us by saying that these names are predictable. The only thing that is predictable about them is that they are unambiguous at the current moment; they should *not* be names you use in things like firewall rules!
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Tue Jun 18, 2013 2:50 pm    Post subject: Reply with quote

I think that the whole "race" issue is very much overblown and is being used more as
a "political football" by those who have another agenda entirely.

I've used multiple network adapters (some similar, some dissimilar) with them being modules
for many years and never had a problem. True when udev became the norm,
I stuck with the mac address scheme, but I was aware that if I changed the network adapter that
I would have to edit a file once to set things the way I wanted them to be.
Just as it was before I changed adapters.

If they wanted predictable names and they were afraid of race conditionns then instead of eth0
they should have used net0 or something similar and left the whole mac addressing scheme as the default.

Oh well, it is what it is.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.19, gcc-4.9.2, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2011)
Back to top
View user's profile Send private message
broken_chaos
Guru
Guru


Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada

PostPosted: Tue Jun 18, 2013 3:33 pm    Post subject: Reply with quote

mv wrote:
I misunderstood you then. Yes, this is not so easy to achieve. But is this really something that somebody wants? I.e. if you have inserted into a machine 10 wifi sticks then the next will be wn11 and stored forever?

I'd take it and be pretty happy with it, myself, since that's how udev has functioned for the past many years, just with a different namespace. I can't remember seeing many complaints about the behaviour of storing persistent interface names for all eternity over the past several years, certainly not as many as I've seen recently about the new names.

It's overall not a huge deal to me, though, aside from thinking the naming scheme is somewhere between overly complex and poorly thought-out for a default, since it is relatively easily avoided if one's not scared of text files (thankfully udev was smart enough to not use XML or a binary format... yet). I intend to do just what you noted about manually assigning names via MAC addresses on machines with more than one interface, since I do really dislike the complexity and length of the new names. My memory's not too bad, but trying to keep track of which machine has an "enp1s4", which has "enp5s2", and which has "wlp4u7" would just make my head hurt after too long.
Back to top
View user's profile Send private message
Prenj
n00b
n00b


Joined: 20 Nov 2011
Posts: 16

PostPosted: Tue Jun 18, 2013 4:08 pm    Post subject: Reply with quote

Indeed. Maybe developers need to understand that interfaces and variable names in general should follow the usual human intuitive scheme. If they do not know what that is, because of some underlying condition that they never bothered to seek councelling for, they can simply ask around.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Tue Jun 18, 2013 7:16 pm    Post subject: Reply with quote

broken_chaos wrote:
I can't remember seeing many complaints about the behaviour of storing persistent interface names for all eternity over the past several years

I have seen many such complaints in usenet. Even more complaints of the type "after exchanging my network card, I do not have eth0 anymore, although any sane system should see that I have only one card and thus want it as eth0". udev was frequently heavily attacked because of this (though I remember these discussions mainly from German usenet, so it makes no sense to give references here). The new default at least partly "solves" this complaint.
Back to top
View user's profile Send private message
Aiken
Tux's lil' helper
Tux's lil' helper


Joined: 22 Jan 2003
Posts: 148
Location: Toowoomba/Australia

PostPosted: Tue Jun 18, 2013 8:57 pm    Post subject: Reply with quote

mv wrote:
Even more complaints of the type "after exchanging my network card, I do not have eth0 anymore, although any sane system should see that I have only one card and thus want it as eth0".


I have had that happens a few times. Easily fixed by deleting the offending 70- rule. I also regard that as another case where udev could have left the network interface names alone.
_________________
Beware the grue.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3638
Location: The Peanut Gallery

PostPosted: Wed Jun 19, 2013 7:34 pm    Post subject: Reply with quote

mv wrote:
Even more complaints of the type "after exchanging my network card, I do not have eth0 anymore, although any sane system should see that I have only one card and thus want it as eth0".

Which is exactly what the default kernel rules do.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Thu Jun 20, 2013 9:59 am    Post subject: Reply with quote

mv wrote:
broken_chaos wrote:
I can't remember seeing many complaints about the behaviour of storing persistent interface names for all eternity over the past several years

I have seen many such complaints in usenet. Even more complaints of the type "after exchanging my network card, I do not have eth0 anymore, although any sane system should see that I have only one card and thus want it as eth0". udev was frequently heavily attacked because of this


There were very few complaints that I remember and I've been using linux since before 1.0 version.
Udev itself has been around since only 2003

I've replaced my single card a few times and as Aiken said it was as simple as removing the 70 rule file.

Hardly the same league of problems or amount of problems as there are with this latest abomination called udev.

As I said earlier the udev/systemd sycophants are sure trying hard to make the old problems seem as vast as the new problems
and they just aren't so they look foolish for even trying that tactic, IMO.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.19, gcc-4.9.2, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2011)
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Fri Jun 21, 2013 3:26 pm    Post subject: Reply with quote

steveL wrote:
mv wrote:
Even more complaints of the type "after exchanging my network card, I do not have eth0 anymore, although any sane system should see that I have only one card and thus want it as eth0".

Which is exactly what the default kernel rules do.

Which is why I misunderstood broken_chaos' request: For many people, the configuration I posted is perhaps optimal (although, personally, I prefer net%n or lan%n). However, Linux always has the tendency to prefer the defaults for large-scale systems (e.g. also the scheduler is written with scalability in mind although there were schedulers which were faster on few-processor systems which most people have), so in a sense it is just consequent to choose a default which prefers users with several ethernet cards.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3638
Location: The Peanut Gallery

PostPosted: Mon Jun 24, 2013 6:13 am    Post subject: Reply with quote

mv wrote:
For many people, the configuration I posted is perhaps optimal (although, personally, I prefer net%n or lan%n).

No for 99% of people the previous defaults were optimal.
Quote:
However, Linux always has the tendency to prefer the defaults for large-scale systems (e.g. also the scheduler is written with scalability in mind although there were schedulers which were faster on few-processor systems which most people have), so in a sense it is just consequent to choose a default which prefers users with several ethernet cards.

That's a total non-sequitur. It's about as consequent as "reliable intelligence" and its use as justification for war against a "clear and present threat".

Simply put, a more reliable mechanism should have been put in place in the first place, and given that it wasn't and years of configuration are the result, a mechanism that enables machines to keep running should've been put in place.

Not someone's grand "new idea" which is even worse than the last one.

Total amateur hour AFAIC. You as ever, can believe what you want.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Mon Jun 24, 2013 1:48 pm    Post subject: Reply with quote

steveL wrote:
mv wrote:
For many people, the configuration I posted is perhaps optimal (although, personally, I prefer net%n or lan%n).

No for 99% of people the previous defaults were optimal.

I have no statistics, that's why I do not claim any numbers, but I guess many people have only one ethernet and one wireless device, and for these people the suggested configuration is perfect. If they would get another device, they still could manually fix it.
The previous udev default appeared always a bit strange to me, because it tried to be too clever: I always thought that a self-modifying configuration was not the best idea. I prefer to do my configuration manually and not have any automatism with root permissions mess with it, so the first thing I did was to switch it off on all of my machines for which I had root permissions. But this is certainly also a question of taste. Anyway, with the race even this self-modification of the configuration could fail its goal of being completely persistent, so the previous udev configuration (with the race) was a complete disaster.
Quote:
Quote:
However, Linux always has the tendency to prefer the defaults for large-scale systems (e.g. also the scheduler is written with scalability in mind although there were schedulers which were faster on few-processor systems which most people have), so in a sense it is just consequent to choose a default which prefers users with several ethernet cards.

That's a total non-sequitur. It's about as consequent as "reliable intelligence" and its use as justification for war against a "clear and present threat".

I do not understand (linguistically) you previous sentence. What I meant is that if the default would have been a configuration like I had suggested then only users with only one ethernet/wifi card have no problems - even if this perhaps is the majority of users - while for all enterprise systems with more cards non-persistency would have to be expected which is somewhat against the tendency of linux (meaning linux - the kernel) of preferring enterprise systems.
Quote:
Simply put, a more reliable mechanism should have been put in place in the first place

Do you know any which behaves for all use cases as it should without manual configuration? Of course, this would be optimal, but I cannot imagine that such a mechanism exists: All mechanisms which I can imagine fail in one or another important case without manual interference. Of course, this is not a mathematical proof that such a thing cannot exist... How do other OSes (BSD, SunOS, Windows, Apple) solve this problem? Or does the problem not occur for these OSes, because they have a well-defined order in which the hardware is initialized? (The latter is of course the real cause of the problem: udev is just an invention which artificially tries to minimize the effect of the behavior of the kernel for the user, but as we can see now it seems that it cannot do this without other drawbacks,)
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3638
Location: The Peanut Gallery

PostPosted: Mon Jun 24, 2013 8:07 pm    Post subject: Reply with quote

mv wrote:
the previous udev configuration (with the race) was a complete disaster.

You misunderstand me: I meant the defaults in the kernel, as I referred to originally.
Quote:
Quote:
Quote:
However, Linux always has the tendency to prefer the defaults for large-scale systems (e.g. also the scheduler is written with scalability in mind although there were schedulers which were faster on few-processor systems which most people have), so in a sense it is just consequent to choose a default which prefers users with several ethernet cards.

That's a total non-sequitur. It's about as consequent as "reliable intelligence" and its use as justification for war against a "clear and present threat".

I do not understand (linguistically) you previous sentence.

Simply this: it is by no means "consequent" to choose such a default. Each thing should be considered in its own regard, and the kernel defaults are fine for most people, especially all the desktop users the userspace convenience layers are aimed at.
Quote:
Quote:
Simply put, a more reliable mechanism should have been put in place in the first place

Do you know any which behaves for all use cases as it should without manual configuration?

Where on earth did the requirement for "no manual configuration" come from? You certainly aren't trying to seriously posit that any of the mechanisms "delivered" in the last few years have required zero configuration for multiple adaptors, are you?

Anyhow, you've been involved in other threads where this has been discussed, so I'm not repeating myself just because you're feeling disingenuous.
Back to top
View user's profile Send private message
slamp
n00b
n00b


Joined: 11 Jun 2009
Posts: 2

PostPosted: Wed Jul 03, 2013 1:44 pm    Post subject: Reply with quote

Sorry for the UP, how can we update Gentoo Handbook so it is consistent with the new predictable network interface names ?
http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=8

I just installed a new gentoo and network was not up due to the new interface name.
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Fri Jul 05, 2013 2:25 pm    Post subject: Reply with quote

I have always been satisfied with the kernel's network device naming,
but I could see how the argument for persistent network interface
names makes sense on servers with a lot of network interfaces.

Persistent network interface names would be more convenient to use
with simpler configuration that would be more obvious to new users.
We have this /etc/conf.d/net file that new Gentoo users usually need
to find and comprehend (more or less) to get started. It seems obvious
to have a block in there for network interface naming for users that find
the kernel device names potentially risky:
Code:

# Assign persistent network interface names to mac addresses;
# these will replace the kernel's eth0, wlan0, etc network device names
# at runtime.
# ethernet
#net0=[mac address]
#net1=[mac address]
#....
# wifi
#wnet0=[mac address]
#wnet1=[mac address]
#....
# other
# expnet0 = [mac address]
# expnet1 = [mac address]
....


Users generally need to find out their mac addresses to configure
their routers, sometimes for iptables for users that use iptables
Code:

-m mac [\!] --mac-source [mac address]

options, and so on, so they normally have this information at hand
anyway when installing on a new system or changing hardware.

New users will figure out a scheme like this in a jiffy, simply by looking
at it, and they won't even relate it to udev, they will simply see it as
"Gentoo network configuration."
_________________
TIA
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Fri Jul 05, 2013 5:43 pm    Post subject: Reply with quote

slamp wrote:
Sorry for the UP, how can we update Gentoo Handbook so it is consistent with the new predictable network interface names ?
http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=8

I just installed a new gentoo and network was not up due to the new interface name.


The page you mentioned says (now),

Quote:

Note: This assumes that your network interface will be called eth0. This is, however, very system dependent. It is recommended to assume that the interface is named the same as the interface name when booted from the installation media if the installation media is sufficiently recent. More information can be found in Network Interface Naming[1]

[1] http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=4&chap=2#doc_chap4
Back to top
View user's profile Send private message
_______0
Guru
Guru


Joined: 15 Oct 2012
Posts: 521

PostPosted: Fri Jul 05, 2013 9:32 pm    Post subject: Reply with quote

I have a solution.

Whenever you tipe ifconfig -a, or ip, a giant jpeg cartoon with LAYOUT of your mobo showing you where the ethernet devices are physically located. Then you click on the interface that you mean to use for configuration.

And if you type ifconfig 'interface' the same giant jpeg cartoon with corresponding device with a red circle BLINKING.

problem solved.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3638
Location: The Peanut Gallery

PostPosted: Sat Jul 06, 2013 7:27 am    Post subject: Reply with quote

wcg wrote:
I have always been satisfied with the kernel's network device naming, but I could see how the argument for persistent network interface names makes sense on servers with a lot of network interfaces.

Sure. It's just not needed for the vast majority of desktops or laptops, where eth0 and wlan0 (irrespective of changing NIC, which usually only happens on an upgrade) are ideal. Almost as if linux developers had been using the same setup for their machines.. ;-)
Quote:
Persistent network interface names would be more convenient to use with simpler configuration that would be more obvious to new users.

Agreed. And to all of us. Simple plain-text configuration is much easier in the long-term for everyone, including automation.

However, as we've discussed in other threads, a file the kernel reads (based on a kcmdline param iff the option is even switched on, or compiled in for server farms) at bootup (ie before any network drivers can start) to reserve ifnames would address the legacy configuration issue. So people who have years of configuration and scripts that use eth0-X on servers, will not have a maintenance nightmare just because they used what was recommended a few years ago by the same developers, and the race problem is solved.

It's not a major patch: file reading goes on at that point already, to load init. And no extra logic runs at any point except for startup, and at NIC-device bring-up, a very quick list check that does not affect normal operation. (And could be a patched-nop/branch over call, similar to tracing, if not using the compiled-in option, say for standard desktop builds.)

So it wouldn't be in /etc/conf.d/net, but say /etc/ifname, and would not depend on init-system, but only on whether the admin configured it. We'd basically got to:
Code:
# reserve ifname $2 for hw mac address $1 - spoof externally as $3 if given
[mac:address]  ifname  [optional:spoof]
but I guess the ifname first makes more sense for the user. (The spoof would be useful if you have multiple virtual machines with the same virtual hardware.)

This is the same idea as /etc/mactab (which I think is busybox, iirc.)
Quote:
Users generally need to find out their mac addresses to configure their routers, sometimes for iptables for users that use iptables options, and so on, so they normally have this information at hand anyway when installing on a new system or changing hardware.

Exactly. Someone else mentioned that NICs often have the hardware MAC address on a sticker. And at the level of device bring-up, it doesn't change, so we can rely on it to identify the device at kernel-level.
When you're changing NIC is when you're in the right frame of mind to deal with changing the config file. Once you've done that, using a MAC-ifname mapping reservation, it's fire-and-forget until you come to physically remove the NIC.

Now to find a C coder with kernel knowledge to write the patch, and someone to test it.. :-)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8
Page 8 of 8

 
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