On Sat, 26 Aug 2017 at 19:57:34 +0200
Didier Kryn <kryn@???> wrote:

> Le 26/08/2017 à 19:02, Alessandro Selli a écrit :
>> On Sat, 26 Aug 2017 at 17:19:48 +0200
>> Didier Kryn <kryn@???> wrote:
>>

>>>       AFAIR I fully agreed on that and then it jumped into my face that
>>> the renaming wasn't necessary at all, because it is sufficient to know
>>> the MAC address and ignore completely the interface name. It is just
>>> enough for this to work that the tools manipulating the network
>>> interfaces can be given the MAC address instead of the interface name.
>>> This opens an alternative to renaming: guaranteed stable interface
>>> reference, no race condition and no need for a new name space.  
>>    This is not a good solution when you want networking to work just the
>> same even when you replace or shuffle your networking hardware around,
>> expecially with USB devices.  

>

>      Please could you explain why with more details?

Suppose you have a laptop you use both at work and home. You configured
the built-in WiFi in a way that is best suited to connect to your home
network, and you configured a USB-WiFi adaptor with different firewall
policies for when you use it from work (maybe you use it to connect home via
a VPN that can only go trough a specific Access Point). Of course you don't
like sudo-ing your config files every time you change of USB-WiFi adaptor,
you'd like your iptables -o wlan1 ... rules to always apply to the USB-WiFi
adaptor even when you change it or use a colleague's one test a new one.

But wlan* names are assigned by the kernel and sometimes strange things do
happen, like that while kernel 4.8 used to load the iwlwifi module (builtin
WiFi) before the r8169 one if you booted the PC with the USB-WiFi adaptor
inserted, kernel 4.12 does the opposite.
This did not happen to me with WiFi gear, but I know a guy who run into
this issue with webcams, because his laptop's internal one was connected to
the motherboard via a USB port. If he booted with a second webcam plugged
in, that webcam would be /dev/video0 and his scripts would use the wrong one.

If you're playing with Software Defined Networking, and maybe assembled a
PC with a number of multi-ethernet PCIe cards, then such issues do pop up
from time to time and can be a serious nuisance if that PC replaced your
employer's old Cisco switch and an upgrade and reboot made the LAN
inaccessible while you're on vacation ;-)

I don't now if NIC suffer from the same issue hard disks suffer from, that
is ageing that causes activation/initialisation time to grow with time. A
problem with HDs is not just that from a kernel version to a following one
modules might load in a different sequence, but that disks take longer to
spin-up and to report themselves on-line as they age. As HDs do not age the
same way, it can happen that in an array disk2 reports itself online before
disk1 and is thus assigned sda by the kernel. However after a few years it
goes on-line after disk1, and is thus assigned name sdb. I don't know if
NICs can suffer from the same issue, though I expect devices that have mo
mechanical parts to age much more gracefully. But then, electronics too grow
old and see their parameters change somewhat, even though so far I only
experienced MII ethernet transceivers to just stop working.

>>>       Since this last method is exactly what is done to refer to disk
>>> partitions in both the mount utility and the fstab, the same could be
>>> done with the MAC address of the network interfaces.  
>>    This is easily done on filesystems, because you can assign arbitrary
>> UUIDs and LABELs on a filesystem at mkfs time or later with tune2fs and
>> other tools. But you cannot as easily change MAC address on an ethernet
>> or WiFi device, sometimes you cannot do it at all (AFAIK in some cases
>> you should reflash an internal flash memory).  

>

>      You assign UUIDs because partitions dont come with hardwired UUIDs, 
> obviously.

This makes them very useful because they both allow one to always identify
the right filesystem no matter how the kernel today is calling the device it
lives on, and they can be arbitrarilly assigned by the superuser.

> The usefull property of UUIDs is in their name ("unique"),
> not at all the fact that you (randomly) assign them. The same applies to
> MAC addresses, they are (quasi) unique.

MAC lacks the arbitrary assignement property. Some (many?) NICs do allow
their MAC to be changed by software (driver or specially built application),
because the MAC is recorded on an on-bloard flash. But it's permanent
modification is not as easy as changing a filesystem's UUID/LABEL, as this
operation need specific kernel support (that I think is often missing).

>>> Which raises
>>> another question: why are we using the hotplugger to mess with interface
>>> names instead of implementing the MAC handle in the ip utility and the
>>> interfaces file.  
>>    Because in most cases networking on eth0 must work no matter what it's
>> MAC address is today/was yesterday.  
>      The problem is how to configure eth0. If you have only one nic, 
> then it's clear; otherwise you don't want to mess.

>

>      With my proposed solution, the admin has the choice to refer to 
> nics by their interface name, as given by the kernel, which is fine when 
> there is only one, or by their MAC address, if there are several.

It's not so fine if you want a NIC to be assigned the same name even if
it's hardware address changed (I use a different USB-WiFi adaptor, and I
want everything to work like it did with the previous one).

> If you
> use MAC you get the same result as with current Devuan's udev renaming
> scheme

Just to see if I'm getting it right. Suppose I have two NICs, the built-in
one, eth0, and a USB-ethernet adaptor, eth1. I configure the MAC-sensitive
system to assign these names:

MAC0 -> en0
MAC1 -> en1

Suppose some day I do not use eth1 but plug-in a third device, eth2. What
name is it going to be assigned? en2? I expect it to do so, because were I
to plug-in the eth1 adaptor at a later time then it must be assigned the
en1 name as per system configuration file. If this is what happens, I run
again into the ethernet-device naming issue: I have two NICs, I want the
built-in to always be reporte as en0, the second one must always be en1 for
some software to work the same regardless of what I'm using as the second NIC
today. Since I cannot (easily) reflash the adaptor's MAC address, I
must reconfigure the system settings to reflect this hardware change. Which
is just what the NIC renaming system was aimed to avoid.

> -without the race - and if you use eth0 then you get the same
> result as if you disabled renaming. And you can mix things if you like
> in /etc/interfaces, eg use wlan0 for wifi and MAC for the Ethernets; it
> isn't a decisipon of the distro; it is up to the admin. Just like for
> partitions. Simplicity and choice, that's Unix, isn't it :-)

This idea does has some merit, but it cannot always prevent the necessity
to reconfigure a system's networking due to a hardware change and to a
sysadmin's specific needs; sometimes a cars with NIC 0b:45:81:f4:3e:01 is to
be en1, sometimes a never-before-seen card needs to be given the same name.
How is the system supposed to know? It cannot, the sysadmin will still need
to adjust thing by hand according to what it's needed in the specific
circumstances. I'd like a system that was as simple as possible to configure
and maintain that made this renaming as straightforward as possible, not as
complicated ad udev rules are.

>>> And why are the potterguys now promoting their
>>> complicated name space, if not to make the system always more
>>> complicated  
>>    I do agree their solution is far from elegant.

>>

>>> to solve a problem they have invented themselves?  
>>    I do not agree: in many cases when a machine has several NICs there are
>> real issues with the kernel's naming scheme.  

>

>      Seems (to me) you didn't get my point.

Could be. I'm sorry if I did. Maybe I'll get straight your next
explanation! :-)

> Sorry I failed to explain or I failed to understand your objections :-)

I hope I made my point sufficiently clear in this (too verbose) reply.


Bye,


Alessandro