:: Re: [DNG] if2mac init.d service for…
Góra strony
Delete this message
Reply to this message
Autor: tito
Data:  
Dla: dng
Temat: Re: [DNG] if2mac init.d service for persistent network interface names
On Thu, 24 Dec 2020 00:40:58 +0100
Didier Kryn <kryn@???> wrote:

> Le 24/12/2020 à 00:24, Antony Stone a écrit :
> >>     Or maybe the kernel is much faster than Eudev and it has the
> >> time to create the interfaces faster than Eudev processes them.
> > That sounds likely.

> >
> >>     But for sure the mechanism worked in the past.
> > I completely agree.

> >
> > As I said in my opening posting on the "Ethernet names revisited"
> > thread:
> >
> > | I'm trying to work out how to give those interfaces the names I
> > want; the | motherboard as eth0, and the PCI card as eth1 / eth2.
> > |
> > | Historically, I've been used to udev
> > and /etc/udev/rules.d/70-persistent- | net.rules doing this, where
> > I can specify the name I want for each interface | according to its
> > MAC address.
> >
> > By "historically" I meant "up to Jessie, and I think also Stretch /
> > Ascii". It's not doing the same in Buster / Beowulf.
>
>     Maybe the kernel used to give a chance to udev to rename the
> interfaces and, for some reason, it stopped doing it. And the reason
> might be there's no point given the new fashion of naming the
> interfaces with complicated names.
>
>     It remains possible to do what you want by the mean of a temporary
> name and permutations, or by the method of Tito which uses several
> temporary names, but is generic. But I agree it is irritating to not
> be able to use Udev since it's sitting there anyway.
>
>

Hi,
still I'm not satisfied by my approach as there are a few shortcomings
that I can think of:

1) if2mac does rename in the first pass only the interfaces in
     if2mac.conf  so if there are other interfaces or if they are  added
     later name collisions are still possible in the second pass.
     A workaround could be to rename all existing interfaces but this
     could leave some interfaces not included in the config file
     half-renamed in the end or you need to rename them back to
     the original name in a third pass (if the name is still available,
     otherwise you need to find a arbitrary new one).  
     Still don't know how to handle this in a simple and clean way.
2)  I suspect that if you rmmod and insmod the nic's or wlan's
     module the old names will be assigned by udev/eudev so some
     kind of interaction with udev is still needed.
3)  it would be optimal to make it accept a config dir that can hold
     multiple config files so that you can name some nics WAN*
     some others LAN* and others OPT*  but this would add even more
     complexity.


in the end it would be best to fix udev/eudev and let it handle it
like it did before.
A workaround could be to use names that differ totally from the
old and the "******* predictable names" like (LAN1, OPT1, WIFI1)
but changing of all configs is needed and this was what I wanted
to avoid when I started this attempt.
As we have 4 days of lockdown there is plenty time to think about it....

Ciao,
Tito

 BTW: I noticed during my test that even pci bus numbers can 
         change wildly in the predictable names case (vs MACS,
         if I recall it correctly).
         I thought that being tied to soldered sockets on the motherboard 
         they were immutable. Are they numbered on a first come
         first served basis? or where is my error?