:: Re: [DNG] if2mac init.d service for…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: dng@d404.nl
Fecha:  
A: dng
Asunto: Re: [DNG] if2mac init.d service for persistent network interface names
On 18-12-2020 14:41, tito via Dng wrote:
> On Fri, 18 Dec 2020 10:36:01 +0100
> Didier Kryn <kryn@???> wrote:
>
>> Le 18/12/2020 à 00:17, tito via Dng a écrit :
>>> Hi,
>>> a few days ago I was able to complete may new router
>>> with 12 nics and 1 wifi. I moved the devuan drive from
>>> my previous defunct box to the new one and experienced
>>> all the problems reported in the "Ethernet names revisited"
>>> thread.
>>> I tried all the wise advice of the thread included my own
>>> just to discover that nothing really works reliably.
>>>
>>> Things I've tried in various combinations:
>>>
>>> 1) 70-persistent-net.rules with mac
>>> 2) 70-persistent-net.rules with pci bus numbers
>>> 3) 60-persistent-net.rules with mac
>>> 4) 60-persistent-net.rules with pci bus numbers
>>> 5) net.ifnames=0 / net.ifnames=1 in grub
>>> 6) biosdevname=0 in grub
>>> 7) renaming the interfaces in /etc/network/interfaces
>>> 8) using ifrename
>>>
>>> Always the 12 nics came up with different names,
>>> or some of them were missing due to collisions
>>> during the rename process and the router was
>>> borked with me yelling.
>>> Especially sarcastic I've found the definition of
>>> the new "predictable names" because there is
>>> nothing really predictable about them and at every
>>> reboot they can be totally different, one time being
>>> enp5s0 and next time enp8s0f1 depending on
>>> the BIOS initialization process ( I suppose....).
>>> At the end I started thinking about a KISS way to get
>>> my persistent interface names back without
>>> using udev/eudev or other non cooperative software.
>>> I've come up with a init script that I've called
>>> if2mac that matches interfaces to mac addresses
>>> early in the boot process before networking is set up,
>>> that for me works reliably (after a night of reboots).
>>> I post it here so that If some bold beta testers on the list
>>> are interested they can try it out in the hope that
>>> it works for them (and AT THEIR OWN RISK!!!).
>>> To use it copy the script to /etc/init.d/:
>>>
>>> cp if2mac /etc/init.d/
>>> chmod +x /etc/init.d/if2mac
>>> insserv if2mac
>>>
>>> and the configuration file to /etc/if2mac.conf.
>>>
>>> ## Sample configuration file for if2mac.
>>> ##
>>> ## WIRED_MAC_LIST and WIRELESS_MAC_LIST contain a list of MAC
>>> ## addresses in the desired order top to down starting at
>>> ## position 0. For example:
>>> ## WIRED_MAC_LIST="\
>>> ## 00:11:22:33:44:54 \ <= The space is needed!!!
>>> ## 00:11:22:33:44:55 \
>>> ## 00:11:22:33:44:56"
>>> ## The WIRED_PREFIX and WIRELESS_PREFIX variables can be changed
>>> ## at your liking (opt, port, whatever).
>>>
>>> WIRED_PREFIX="eth"
>>>
>>> WIRED_MAC_LIST="\
>>> 00:12:21:c4:56:68 \
>>> 00:12:21:c4:56:69 \
>>> 00:13:21:c4:56:6a \
>>> 00:13:21:c4:56:6b \
>>> 00:33:18:04:a3:46 \
>>> 00:34:18:04:a3:47 \
>>> 00:35:18:04:a3:48 \
>>> 00:36:18:04:a3:49 \
>>> 00:36:18:04:a3:4a \
>>> 00:36:18:04:a3:4b \
>>> 00:36:18:04:a3:4c \
>>> 00:56:18:04:a3:4d"
>>>
>>> WIRELESS_PREFIX="wlan"
>>>
>>> WIRELESS_MAC_LIST="\
>>> 54:2a:a2:2b:b3:55"
>>>
>>> Attached you will find the init script and a sample
>>> configuration file. Multiple configuration files
>>> to allow more prefixes are not supported because
>>> this kind of renaming could be done in /etc/network/interfaces
>>> once the interfaces came up with predictable and persistent names.
>>> At this time only
>>>
>>> en      Ethernet wired
>>> et     Ethernet wired old
>>> wl     Wireless local area network (WLAN)

>>>
>>> interfaces are supported with both old style
>>> and new "predictable" names.
>>>
>>> Prerequisites are:
>>> /bin/cat
>>> /sbin/ip
>>> and a mounted /sysfs.
>>>
>>> Hints improvements and critics are welcome.
>>> Eventually if there is some interest this could be packaged
>>> (with the help of some devuan packaging gurus).
>>>
>>> Hope this helps. Enjoy.
>>> Ciao,
>>> farmatito
>>     Looks like the cleanest thing to do to workaround non-cooperative
>> software, as you write. I'ts a pitty to be forced to that, but, at
>> first read it looks well done. I didn't try it because nowadays I
>> only use computers with ar most one eth and one wifi. Just found
>> typos in a comment:
>>
>> # We need to passes to allow interface swappin
>>
>> should be
>>
>> # We need two passes to allow interface swapping
>>
>> Well done.
>>
>> --         Didier
>>
> Hi,
> Thanks, typo fixed.
>
> Ciao,
> Tito
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Workarounds are great of course but I found that default eudev does not
compile with --enable-rule-generator anymore and that is likely the
reason this problem has appeared now.

>
>     # rule-generator - persistent network and optical device rule generator

>
>     #
> ------------------------------------------------------------------------------

>
>
>     AC_ARG_ENABLE([rule-generator],

>
>     AS_HELP_STRING([--enable-rule-generator], [enable legacy persistent
> network, cdrom support]),

>
>     [], [enable_rule_generator=no])

>
>     
>
>     if test "x${enable_rule_generator}" != xno; then

>
>     AC_DEFINE([ENABLE_RULE_GENERATOR], [1], [Define if we are enabling
> rule generator])

>
>     fi

>
>     
>
>     AM_CONDITIONAL([ENABLE_RULE_GENERATOR], [test
> "x$enable_rule_generator" = xyes])

>
>

My systems are still on ASCII so i cannot confirm it will work after
recompiling.

Grtz.

Nick