:: Re: [DNG] if2mac init.d service for…
Pàgina inicial
Delete this message
Reply to this message
Autor: Curtis Maurand
Data:  
A: dng
Assumpte: Re: [DNG] if2mac init.d service for persistent network interface names
because system bios is running a version of embedded linux and it dynamically populates things at boot up. the only immutable bit is the interface’s mac.

Sent from my iPhone

> On Dec 24, 2020, at 8:24 AM, tito via Dng <dng@???> wrote:
>
> 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?   

>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng