Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi,

On 25/12/20 22:41, aitor wrote:


Hi,

On 23/12/20 21:56, aitor wrote:
Another way might be the use of vdev actions, but vdev is a work in 
progress.


Indeed, vdev already has a helper for that:

https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/ifname.sh 



Cheers,

Aitor.

Sorry for my replicated emails. It's usual when I replay from the sent 
emails, instead of from the received emails.


Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi,

On 23/12/20 21:56, aitor wrote:
Another way might be the use of vdev actions, but vdev is a work in 
progress.


Indeed, vdev already has a helper for  that:

https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/ifname.sh 



Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi,

On 23/12/20 21:56, aitor wrote:
Another way might be the use of vdev actions, but vdev is a work in 
progress.


Indeed, vdev already has a helper for that:

https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/ifname.sh 



Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Fri, 25 Dec 2020 10:09:18 -0500
Steve Litt  wrote:

> On Fri, 25 Dec 2020 09:57:43 +0100
> tito via Dng  wrote:
> 
> > On Thu, 24 Dec 2020 21:11:49 -0500
> > Steve Litt  wrote:
> > 
> > > On Thu, 24 Dec 2020 16:32:18 +0100
> > > tito via Dng  wrote:
> > >   
> > > > On Thu, 24 Dec 2020 10:10:07 -0500
> > > > Steve Litt  wrote:
> > > >   
> > > > > On Wed, 23 Dec 2020 23:41:58 +0100
> > > > > Didier Kryn  wrote:
> > > > > 
> > > > > > Le 23/12/2020 à 22:03, Antony Stone a écrit :
> > > > > > > If the kernel decides A=eth1, B=eth2, C=eth0 then there's
> > > > > > > no way for udev rules to rename them, because "File
> > > > > > > exists" (which should of course say "Device name exists").
> > > > > > > 
> > > > > > 
> > > > > >     This should not happen and did not happen in the past
> > > > > > because the interfaces are created sequentially. 
> > > > > 
> > > > > Yes it did. It happened in the 1900's. We were all advised
> > > > > never to use the same type of network card for both
> > > > > interfaces, because which card became eth0 would be
> > > > > indeterminate. I had eth0 magically switch to eth1, and then
> > > > > back again, several times.
> > > > > 
> > > > > Earlier in this thread I submitted a shellscript that fixes
> > > > > this whole problem, without all sorts of udev raindances.
> > > > > 
> > > > > SteveT
> > > > > 
> > > > > Steve Litt 
> > > > 
> > > > Hi,
> > > > is it this one? How does it solve my problem to rename
> > > > interfaces according to their mac address without 
> > > > name collisions (plus corner cases)?
> > > > 
> > > > #!/bin/sh
> > > > # Copyright (c) 2016 by Steve Litt
> > > > # Expat license. See http://directory.fsf.org/wiki/License:Expat
> > > > 
> > > > chosen_wifi_number=${1:-1}
> > > > wifidevs=0
> > > > 
> > > > for dev in `ip -o link | sed -n 's/[^:]*: *\(w[^:]*\).*/\1/p'`;
> > > > do
> > > > wifidevs=`expr $wifidevs + 1`
> > > > 
> > > > test $wifidevs -eq $chosen_wifi_number && {
> > > > echo $dev
> > > > exit 0
> > > > }
> > > > done
> > > > 
> > > > echo =max$wifidevs
> > > > 
> > > > Ciao,
> > > > Tito  
> > > 
> > > 
> > > It either is the one, or looks a whole lot like it.
> > > 
> > > Note that somebody else on this list made it even better, but I
> > > can't find that email again.
> > > 
> > > If the "w" in the sed command is changed to "e", then it does the
> > > same thing for wired Ether net.
> > > 
> > > The shellscript I wrote spits out one answer. However, it could
> > > easily be modified to do several, either letting you choose, or
> > > perhaps if running exec'ed or dotted, create environment vars like
> > > eth0, eth1, eth2, etc, and wlan0, wlan1, wlan2, etc, so all you
> > > need to do in your shellscripts is change "wlan0" to "$wlan0". As
> > > long as nobody switches slots or jacks, the numbering of these
> > > will be determinate. 
> > > 
> > > SteveT
> > > 
> > > Steve Litt   
> > Hi,
> > What I've experienced is that is that even pci bus numbers change
> > from one reboot to the other so unless you tie the names to the mac
> > address they will not be determinate and my router will not work at
> > best and lock me out in the worst case. On a desktop with 1-2 nics
> > or 1 wifi this is not that big problem as the names will stay
> > mostly the same just due to the low numbers involved.
> > 
> > Ciao,
> > Tito
> 
> That's a good point Tito. What would it take to write a similar
> shellscript using Mac addresses?
> 
> 
> SteveT
> 
> Steve Litt 
Hi,
I'm trying to do it and will post version 0.2 asap to review for the
list members, but there is more complexity than you would expect e.g.:

1) interaction with udev: if you change the names you need to 
  produce a net-persistent.rules file so that if you rmmod and
   insmod the names will stay the same;
2) interaction with net.ifnames=0 or 1: system creates new-style names
 but user wants old-style names and didn't set ifnames=0
3) what to do with ifaces renamed in first pass that were not included in 
if2mac.conf
(yes have to rename them all or interface swapping will not be 
possible)
 a) restore original name: not always possible
 b) rename to user style of names and numbering
  b1) add them to rules file or not
 c) just warn.
 4) make it robust.

This are just a few I recall but there are more.

Ciao,
Tito



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Steve Litt]

On Fri, 25 Dec 2020 09:57:43 +0100
tito via Dng  wrote:

> On Thu, 24 Dec 2020 21:11:49 -0500
> Steve Litt  wrote:
> 
> > On Thu, 24 Dec 2020 16:32:18 +0100
> > tito via Dng  wrote:
> >   
> > > On Thu, 24 Dec 2020 10:10:07 -0500
> > > Steve Litt  wrote:
> > >   
> > > > On Wed, 23 Dec 2020 23:41:58 +0100
> > > > Didier Kryn  wrote:
> > > > 
> > > > > Le 23/12/2020 à 22:03, Antony Stone a écrit :
> > > > > > If the kernel decides A=eth1, B=eth2, C=eth0 then there's no
> > > > > > way for udev rules to rename them, because "File
> > > > > > exists" (which should of course say "Device name exists").
> > > > > > 
> > > > > 
> > > > >     This should not happen and did not happen in the past
> > > > > because the interfaces are created sequentially. 
> > > > 
> > > > Yes it did. It happened in the 1900's. We were all advised never
> > > > to use the same type of network card for both interfaces,
> > > > because which card became eth0 would be indeterminate. I had
> > > > eth0 magically switch to eth1, and then back again, several
> > > > times.
> > > > 
> > > > Earlier in this thread I submitted a shellscript that fixes this
> > > > whole problem, without all sorts of udev raindances.
> > > > 
> > > > SteveT
> > > > 
> > > > Steve Litt 
> > > 
> > > Hi,
> > > is it this one? How does it solve my problem to rename
> > > interfaces according to their mac address without 
> > > name collisions (plus corner cases)?
> > > 
> > > #!/bin/sh
> > > # Copyright (c) 2016 by Steve Litt
> > > # Expat license. See http://directory.fsf.org/wiki/License:Expat
> > > 
> > > chosen_wifi_number=${1:-1}
> > > wifidevs=0
> > > 
> > > for dev in `ip -o link | sed -n 's/[^:]*: *\(w[^:]*\).*/\1/p'`;
> > > do
> > > wifidevs=`expr $wifidevs + 1`
> > > 
> > > test $wifidevs -eq $chosen_wifi_number && {
> > >   echo $dev
> > >   exit 0
> > > }
> > > done
> > > 
> > > echo =max$wifidevs
> > > 
> > > Ciao,
> > > Tito  
> > 
> > 
> > It either is the one, or looks a whole lot like it.
> > 
> > Note that somebody else on this list made it even better, but I
> > can't find that email again.
> > 
> > If the "w" in the sed command is changed to "e", then it does the
> > same thing for wired Ether net.
> > 
> > The shellscript I wrote spits out one answer. However, it could
> > easily be modified to do several, either letting you choose, or
> > perhaps if running exec'ed or dotted, create environment vars like
> > eth0, eth1, eth2, etc, and wlan0, wlan1, wlan2, etc, so all you
> > need to do in your shellscripts is change "wlan0" to "$wlan0". As
> > long as nobody switches slots or jacks, the numbering of these will
> > be determinate. 
> > 
> > SteveT
> > 
> > Steve Litt   
> Hi,
> What I've experienced is that is that even pci bus numbers change from
> one reboot to the other so unless you tie the names to the mac address
> they will not be determinate and my router will not work at best and
> lock me out in the worst case. On a desktop with 1-2 nics or 1 wifi
> this is not that big problem as the names will stay mostly the same
> just due to the low numbers involved.
> 
> Ciao,
> Tito

That's a good point Tito. What would it take to write a similar
shellscript using Mac addresses?


SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Thu, 24 Dec 2020 21:11:49 -0500
Steve Litt  wrote:

> On Thu, 24 Dec 2020 16:32:18 +0100
> tito via Dng  wrote:
> 
> > On Thu, 24 Dec 2020 10:10:07 -0500
> > Steve Litt  wrote:
> > 
> > > On Wed, 23 Dec 2020 23:41:58 +0100
> > > Didier Kryn  wrote:
> > >   
> > > > Le 23/12/2020 à 22:03, Antony Stone a écrit :  
> > > > > If the kernel decides A=eth1, B=eth2, C=eth0 then there's no
> > > > > way for udev rules to rename them, because "File
> > > > > exists" (which should of course say "Device name exists").
> > > > 
> > > >     This should not happen and did not happen in the past
> > > > because the interfaces are created sequentially.   
> > > 
> > > Yes it did. It happened in the 1900's. We were all advised never
> > > to use the same type of network card for both interfaces, because
> > > which card became eth0 would be indeterminate. I had eth0
> > > magically switch to eth1, and then back again, several times.
> > > 
> > > Earlier in this thread I submitted a shellscript that fixes this
> > > whole problem, without all sorts of udev raindances.
> > > 
> > > SteveT
> > > 
> > > Steve Litt   
> > 
> > Hi,
> > is it this one? How does it solve my problem to rename
> > interfaces according to their mac address without 
> > name collisions (plus corner cases)?
> > 
> > #!/bin/sh
> > # Copyright (c) 2016 by Steve Litt
> > # Expat license. See http://directory.fsf.org/wiki/License:Expat
> > 
> > chosen_wifi_number=${1:-1}
> > wifidevs=0
> > 
> > for dev in `ip -o link | sed -n 's/[^:]*: *\(w[^:]*\).*/\1/p'`;
> > do
> > wifidevs=`expr $wifidevs + 1`
> > 
> > test $wifidevs -eq $chosen_wifi_number && {
> > echo $dev
> > exit 0
> > }
> > done
> > 
> > echo =max$wifidevs
> > 
> > Ciao,
> > Tito
> 
> 
> It either is the one, or looks a whole lot like it.
> 
> Note that somebody else on this list made it even better, but I can't
> find that email again.
> 
> If the "w" in the sed command is changed to "e", then it does the same
> thing for wired Ether net.
> 
> The shellscript I wrote spits out one answer. However, it could easily
> be modified to do several, either letting you choose, or perhaps if
> running exec'ed or dotted, create environment vars like eth0, eth1,
> eth2, etc, and wlan0, wlan1, wlan2, etc, so all you need to do in your
> shellscripts is change "wlan0" to "$wlan0". As long as nobody switches
> slots or jacks, the numbering of these will be determinate. 
> 
> SteveT
> 
> Steve Litt 
Hi,
What I've experienced is that is that even pci bus numbers change from
one reboot to the other so unless you tie the names to the mac address
they will not be determinate and my router will not work at best and
lock me out in the worst case. On a desktop with 1-2 nics or 1 wifi
this is not that big problem as the names will stay mostly the same
just due to the low numbers involved.

Ciao,
Tito
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Didier Kryn]

Le 24/12/2020 à 16:40, Hendrik Boom a écrit :
> I remember those days.  I has two different network cards, and things were 
> cnveniently consistent except when I did am upgrade to a new release.  Then, 
> and only them, might they switch places.
>
> Instead of reconfiguring everything, I just switched network cables.
>
> This no longer works today.  I've introduced new consistent names -- 
> something 
> line neth0 and neth1.
>
> And they seem no longer to be considered to be devices.  They are not present 
> in /dev.

    Network devices have never been in /dev. Only character devices and
block devices are.

--         Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Steve Litt]

On Thu, 24 Dec 2020 16:32:18 +0100
tito via Dng  wrote:

> On Thu, 24 Dec 2020 10:10:07 -0500
> Steve Litt  wrote:
> 
> > On Wed, 23 Dec 2020 23:41:58 +0100
> > Didier Kryn  wrote:
> >   
> > > Le 23/12/2020 à 22:03, Antony Stone a écrit :  
> > > > If the kernel decides A=eth1, B=eth2, C=eth0 then there's no way
> > > > for udev rules to rename them, because "File exists" (which
> > > > should of course say "Device name exists").
> > > 
> > >     This should not happen and did not happen in the past because
> > > the interfaces are created sequentially.   
> > 
> > Yes it did. It happened in the 1900's. We were all advised never to
> > use the same type of network card for both interfaces, because which
> > card became eth0 would be indeterminate. I had eth0 magically switch
> > to eth1, and then back again, several times.
> > 
> > Earlier in this thread I submitted a shellscript that fixes this
> > whole problem, without all sorts of udev raindances.
> > 
> > SteveT
> > 
> > Steve Litt   
> 
> Hi,
> is it this one? How does it solve my problem to rename
> interfaces according to their mac address without 
> name collisions (plus corner cases)?
> 
> #!/bin/sh
> # Copyright (c) 2016 by Steve Litt
> # Expat license. See http://directory.fsf.org/wiki/License:Expat
> 
> chosen_wifi_number=${1:-1}
> wifidevs=0
> 
> for dev in `ip -o link | sed -n 's/[^:]*: *\(w[^:]*\).*/\1/p'`;
> do
> wifidevs=`expr $wifidevs + 1`
> 
> test $wifidevs -eq $chosen_wifi_number && {
>   echo $dev
>   exit 0
> }
> done
> 
> echo =max$wifidevs
> 
> Ciao,
> Tito


It either is the one, or looks a whole lot like it.

Note that somebody else on this list made it even better, but I can't
find that email again.

If the "w" in the sed command is changed to "e", then it does the same
thing for wired Ether net.

The shellscript I wrote spits out one answer. However, it could easily
be modified to do several, either letting you choose, or perhaps if
running exec'ed or dotted, create environment vars like eth0, eth1,
eth2, etc, and wlan0, wlan1, wlan2, etc, so all you need to do in your
shellscripts is change "wlan0" to "$wlan0". As long as nobody switches
slots or jacks, the numbering of these will be determinate. 

SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Thu, 24 Dec 2020 16:21:24 +0100
aitor  wrote:

> Hi Tito,
> 
> On 24/12/20 14:24, tito via Dng wrote:
> >   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?
> The following code is supposed to list the mac addresses together
> with the assigned names of
> all your network devices:
> 
> https://www.gnuinos.org/if2mac/ 
> 
> There is a lot of superfluous code on that, because i've just taken
> it from the backend of simple-netaid.
> Since it's has been tested only in the case of an unique wired device 
> and an unique wireless device (my case),
> please can you say if it works fine for you? If so, does the output
> in the command line matches your desired order?
> You need to install libiw-dev, and you can build it via:
> 
> $ gcc if2mac.c -o if2mac -liw
> 
> Thanks in advance,
> 
> Aitor.
> 
> 
> 
> 

Hi,
it works in detecting and listing the devices:

 ./if2mac 
MAC Address=00:xx:xx:xx:xx:47 -> eth5 - wired
MAC Address=00:xx:xx:xx:xx:46 -> eth4 - wired
MAC Address=00:xx:xx:xx:xx:4D -> eth11 - wired
MAC Address=54:xx:xx:xx:xx:62 -> wlan0 - wireless
MAC Address=00:xx:xx:xx:xx:6B -> eth3 - wired
MAC Address=00:xx:xx:xx:xx:4A -> eth8 - wired
MAC Address=00:xx:xx:xx:xx:4C -> eth10 - wired
MAC Address=00:xx:xx:xx:xx:4B -> eth9 - wired
MAC Address=00:xx:xx:xx:xx:49 -> eth7 - wired
MAC Address=00:xx:xx:xx:xx:6A -> eth2 - wired
MAC Address=00:xx:xx:xx:xx:69 -> eth1 - wired
MAC Address=00:xx:xx:xx:xx:68 -> eth0 - wired
MAC Address=00:xx:xx:xx:xx:48 -> eth6 - wired
MAC Address=00:xx:xx:xx:xx:6A -> br0 - wired

The order is somewhat. different.

Ciao,
Tito
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Ian Zimmerman]

On 2020-12-24 10:40, Hendrik Boom wrote:

> And they seem no longer to be considered to be devices.  They are not
> present in /dev.

They never have been there (under Linux), to my best knowledge (and my
history is also long).

Maybe you are thinking of some other system?

-- 
Ian
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Rowland penny via Dng]

On 24/12/2020 15:37, aitor wrote:

does the output in the command line matches your desired order?


Continuing with our English academy: does it match


'does the command line output match your desired order ?'

Also, do not get me started on the use of the word 'since' by non native 
English speakers. 


Rowland


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Hendrik Boom]

On Thu, Dec 24, 2020 at 10:10:07AM -0500, Steve Litt wrote:
> On Wed, 23 Dec 2020 23:41:58 +0100
> Didier Kryn  wrote:
> 
> > Le 23/12/2020 à 22:03, Antony Stone a écrit :
> > > If the kernel decides A=eth1, B=eth2, C=eth0 then there's no way
> > > for udev rules to rename them, because "File exists" (which should
> > > of course say "Device name exists").  
> > 
> >     This should not happen and did not happen in the past because the
> > interfaces are created sequentially. 
> 
> Yes it did. It happened in the 1900's. We were all advised never to use
> the same type of network card for both interfaces, because which card
> became eth0 would be indeterminate. I had eth0 magically switch to
> eth1, and then back again, several times.

I remember those days.  I has two different network cards, and things were 
cnveniently consistent except when I did am upgrade to a new release.  Then, 
and only them, might they switch places.

Instead of reconfiguring everything, I just switched network cables.

This no longer works today.  I've introduced new consistent names -- something 
line neth0 and neth1.

And they seem no longer to be considered to be devices.  They are not present 
in /dev.

Do the deep innards of the kernel still consider them devices even though 
they are no longer present in /dev?  Is this an effect of the devtmpfs 
file system??

-- hendrik

> 
> Earlier in this thread I submitted a shellscript that fixes this whole
> problem, without all sorts of udev raindances.
> 
> SteveT
> 
> Steve Litt 
> Autumn 2020 featured book: Thriving in Tough Times
> http://www.troubleshooters.com/thrive
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

does the output in the command line matches your desired order?


Continuing with our English academy: does it match?


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Thu, 24 Dec 2020 10:10:07 -0500
Steve Litt  wrote:

> On Wed, 23 Dec 2020 23:41:58 +0100
> Didier Kryn  wrote:
> 
> > Le 23/12/2020 à 22:03, Antony Stone a écrit :
> > > If the kernel decides A=eth1, B=eth2, C=eth0 then there's no way
> > > for udev rules to rename them, because "File exists" (which should
> > > of course say "Device name exists").  
> > 
> >     This should not happen and did not happen in the past because
> > the interfaces are created sequentially. 
> 
> Yes it did. It happened in the 1900's. We were all advised never to
> use the same type of network card for both interfaces, because which
> card became eth0 would be indeterminate. I had eth0 magically switch
> to eth1, and then back again, several times.
> 
> Earlier in this thread I submitted a shellscript that fixes this whole
> problem, without all sorts of udev raindances.
> 
> SteveT
> 
> Steve Litt 

Hi,
is it this one? How does it solve my problem to rename
interfaces according to their mac address without 
name collisions (plus corner cases)?

#!/bin/sh
# Copyright (c) 2016 by Steve Litt
# Expat license. See http://directory.fsf.org/wiki/License:Expat

chosen_wifi_number=${1:-1}
wifidevs=0

for dev in `ip -o link | sed -n 's/[^:]*: *\(w[^:]*\).*/\1/p'`;
do
wifidevs=`expr $wifidevs + 1`

test $wifidevs -eq $chosen_wifi_number && {
echo $dev
exit 0
}
done

echo =max$wifidevs

Ciao,
Tito
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

it's has been


it has been... My wooden fingers :)

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi Tito,

On 24/12/20 14:24, tito via Dng wrote:

  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?
The following code is supposed to list the mac addresses together with 
the assigned names of

all your network devices:

https://www.gnuinos.org/if2mac/ 

There is a lot of superfluous code on that, because i've just taken it 
from the backend of simple-netaid.
Since it's has been tested only in the case of an unique wired device 
and an unique wireless device (my case),
please can you say if it works fine for you? If so, does the output in 
the command line matches your desired order?

You need to install libiw-dev, and you can build it via:

$ gcc if2mac.c -o if2mac -liw

Thanks in advance,

Aitor.




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Steve Litt]

On Wed, 23 Dec 2020 23:41:58 +0100
Didier Kryn  wrote:

> Le 23/12/2020 à 22:03, Antony Stone a écrit :
> > If the kernel decides A=eth1, B=eth2, C=eth0 then there's no way
> > for udev rules to rename them, because "File exists" (which should
> > of course say "Device name exists").  
> 
>     This should not happen and did not happen in the past because the
> interfaces are created sequentially. 

Yes it did. It happened in the 1900's. We were all advised never to use
the same type of network card for both interfaces, because which card
became eth0 would be indeterminate. I had eth0 magically switch to
eth1, and then back again, several times.

Earlier in this thread I submitted a shellscript that fixes this whole
problem, without all sorts of udev raindances.

SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Thu, 24 Dec 2020 08:47:17 -0500
Curtis Maurand via Dng  wrote:

> 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.

Thanks,
suspected something like this.

Ciao,
Tito

> Sent from my iPhone
> 
> > On Dec 24, 2020, at 8:24 AM, tito via Dng 
> > wrote:
> > 
> > On Thu, 24 Dec 2020 00:40:58 +0100
> > Didier 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@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Curtis Maurand via Dng]

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  wrote:
> 
> On Thu, 24 Dec 2020 00:40:58 +0100
> Didier 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@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Thu, 24 Dec 2020 00:40:58 +0100
Didier 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@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi tito,

On 22/12/20 8:18, tito via Dng wrote:

BTW I don't know how to achieve this with udev rules
could you be so kind and make a minimal example.


You can invoke your bourne shell script from a new udev.rule via:

IMPORT{program}="script"

If you locate this script in /lib/udev, the path to the script is 
superfluous.
On the other hand, you can define new udev.rule stanzas from the shell 
script
at boot time as follows (in this concrete case, we are using 
70-persistent-net.rules

and previously we source the rule_generator.funcions):


#!/bin/sh -e

RULES_FILE='/etc/udev/rules.d/70-persistent-net.rules'

# Source the rule_generator.funcions:
. /lib/udev/rule_generator.functions

# lock 70-persistent-net.rules, preventing concurrent processes from 
modifying the file at the same time.

lock_rules_file

# Check if the rules file is writeable.
choose_rules_file

# Write the stanza
echo "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", 
ATTR{address}==\"$mac_address\", ATTR{type}==\"1\", KERNEL==\"?*\", 
NAME=\"$name\""

>> $RULES_FILE

# Unlock 70-persistent-net.rules
unlock_rules_file

exit 0


For more instruction, have a look at "/lib/udev/write_net_rules" script.

Hope this helps,

Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

On 24/12/20 10:23, aitor wrote:

neither the mouse nor the keyboard didn't respond
Mmm..., this is a double denial. Neither the mouse nor the keyboard 
could respond?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

On 24/12/20 10:23, aitor wrote:

neither the mouse nor the keyboard didn't respond
Mmm..., this is a double denial. Neither the mouse nor the keyboard 
could respond?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi,


On 19/12/20 15:10, Didier Kryn wrote:

     I think that, like in the case of Mdev, the biggest difficulty is in
emulating libudev, which requires in particular to maintain an
up-to-date database of devices. Jude has done a complete job and libvdev
provides this emulation, but who maintains the database ?


I've been working on vdev during these days, and i'm thinking on a 
possible new approach for it. For instance:


1) We should consider whether or not a separate ABI (libudev-compat) is 
required since the apparition
of libeudev1 (libudev1 without systemd), or leave instead this other 
library (compatible  with libeudev1, or
better said, depending on it) for new features added by Jude Nelson and 
contributors (say the whole libudev-fs.c
or some add-ons like "udev_monitor *udev_monitor_new_from_filesystem" in 
libudev-monitor.c, non existent

in libeudev1)

2) We should also consider the inclusion of a hardware database 
management  tool, call udevadm, vdevadm or
whatever you want. I propose this addition due to the slow boot of the 
system caused by the lack of  this tool,
i guess. In the case of eudev, the hardware database is compiled into a 
binary and only the binary is used at
runtime. I should however add that yesterday I handled vdev with runit 
and the boot process was very quick,
but there is a drawback here: you need to wait for the hardware to be 
detected. In a console session I needed
to wait for the detection of wlan0 (even eth0 was detected inmediately); 
in a X session I couldn't login because

neither the mouse nor the keyboard didn't respond.

Cheers,

Aitor.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Didier Kryn]

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.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Antony Stone]

On Wednesday 23 December 2020 at 23:41:58, Didier Kryn wrote:

> Le 23/12/2020 à 22:03, Antony Stone a écrit :
> > If the kernel decides A=eth1, B=eth2, C=eth0 then there's no way for udev
> > rules to rename them, because "File exists" (which should of course say
> > "Device name exists").
> 
> This should not happen and did not happen in the past because the
> interfaces are created sequentially. Therefore, if you want to rename
> the first one, no name other than eth0 exists yet; and you can figure
> out that something similar happen to the next: the kernel does not name
> it by the name you have assigned to the first one, etc.

No; the problem is that the kernel names all of the interfaces before udev 
gets to do whatever it wants to, therefore by the time my rules saying which 
interface I want as eth0, which as eth1 and which as eth2 are able to run, all 
those names exist, but on the wrong (according to me) devices.

> What may have changed is Eudev managed to not work sequentially. If
> it followed the order in which the interfaces show up out of the
> Netlink, there would be no problem. Therefore I suspect the authors
> managed to launch several threads in order to save 0.01s of the boot
> time. Or to loose more because thread scheduling might well consume more
> than what parallelism saves.

I have no opinion on that.

> 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.


Antony.

-- 
I still maintain the point that designing a monolithic kernel in 1991 is a 
fundamental error.  Be thankful you are not my student.  You would not get a 
high grade for such a design :-)
 - Andrew Tanenbaum to Linus Torvalds

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Didier Kryn]

Le 23/12/2020 à 22:03, Antony Stone a écrit :
> If the kernel decides A=eth1, B=eth2, C=eth0 then there's no way for udev 
> rules to rename them, because "File exists" (which should of course say 
> "Device name exists").

    This should not happen and did not happen in the past because the
interfaces are created sequentially. Therefore, if you want to rename
the first one, no name other than eth0 exists yet; and you can figure
out that something similar happen to the next: the kernel does not name
it by the name you have assigned to the first one, etc.

    What may have changed is Eudev managed to not work sequentially. If
it followed the order in which the interfaces show up out of the
Netlink, there would be no problem. Therefore I suspect the authors
managed to launch several threads in order to save 0.01s of the boot
time. Or to loose more because thread scheduling might well consume more
than what parallelism saves.

    Or maybe the kernel is much faster than Eudev and it has the time to
create the interfaces faster than Eudev processes them.

    But for sure the mechanism worked in the past.

--         Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

On 23/12/20 22:03, Antony Stone wrote:

If the kernel decides A=eth1, B=eth2, C=eth0 then there's no way for udev
rules to rename them, because "File exists" (which should of course say
"Device name exists").


Ok, i understand :)

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Antony Stone]

On Wednesday 23 December 2020 at 21:56:09, aitor wrote:

> I can't understand the problem in the "Ethernet names revisited" thread,

The problem is when the kernel has decided to give your interfaces the names 
you want them to have, but in the wrong order.

> because adding a new rule at the end (for example,
> 98-rename-net-devices.rules)
> containing suggested lines like:
> 
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="?*",
> NAME="new_name"
> 
> is working for me.

You might want A=eth0, B=eth1, C=eth2

If the kernel decides A=eth1, B=eth2, C=eth0 then there's no way for udev 
rules to rename them, because "File exists" (which should of course say 
"Device name exists").

You have to first rename all ethX to somethingelseX, and then you can rename 
them back again in the sequence of your choice.

Maybe you can do this in two separate udev rules files; I did it using one udev 
rules file and network/interfaces.


Antony.

-- 
I have an excellent memory.
I can't think of a single thing I've forgotten.

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi tito,

On 22/12/20 8:18, tito via Dng wrote:

Hi,
I would prefer not to use udev/eudev at all for it and
stick with my KISS approach.
Another way might be the use of vdev actions, but vdev is a work in 
progress.
  
BTW I don't know how to achieve this with udev rules

could you be so kind and make a minimal example.

I can't understand the problem in the "Ethernet names revisited" thread,
because adding a new rule at the end (for example, 
98-rename-net-devices.rules)

containing suggested lines like:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="?*", 
NAME="new_name"


is working for me.

Cheers,

Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Tue, 22 Dec 2020 04:21:40 +
tux...@sapo.pt wrote:

> hello,
> 
> >
> 
> "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"
> 
> >
> 
> You can try to remove eth{0 .. 11} first, via udev rule, and then
> add them again each by its maccaddr..
> 
> Best Regards,
> 
> tux

Hi,
I would prefer not to use udev/eudev at all for it and 
stick with my KISS approach. 
BTW I don't know how to achieve this with udev rules
could you be so kind and make a minimal example.

Ciao,
Tito
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi Didier,

On 19/12/20 15:10, Didier Kryn wrote:

     I think that, like in the case of Mdev, the biggest difficulty is in
emulating libudev, which requires in particular to maintain an
up-to-date database of devices. Jude has done a complete job and libvdev
provides this emulation, but who maintains the database ?


I'm upgrading the library ABI of vdev (libudev1-compat) compatible with 
libudev 241, together with


the hardware database, which is available here:

http://cgit.freedesktop.org/systemd/systemd/plain/hwdb 



I'll try. However, I don't count my chickens... :)

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Didier Kryn]

Le 19/12/2020 à 17:20, aitor a écrit :
>
> Hi,
>
> On 19/12/20 15:22, tito via Dng wrote:
>> is this a database generated at runtime about the devices of the
>> current machine or just a collection of hardware ids/info?
>> In the latter case couldn't we let the udev/systemd people do the
>> work and use their database?
>
> It's the second one.
>
Yep, and this is another issue: since udev/systemd is the master of this
database, they can change it  anytime; I mean not only the data, but the
format.

This is a domain where there is no standard. Even sysfs, the access to
which is part of libudev, isn't stable, which is a good excuse for not
documenting libudev.

But all this is just rant and scare, sorry.

--    Didier



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Sat, 19 Dec 2020 11:40:31 -0800
Ian Zimmerman  wrote:

> On 2020-12-18 21:28, tito via Dng wrote:
> 
> > I love physical connections therefore I prefer NICs over Wifi, so 12
> > of them are not so much (a few clients, a server, pos, couple of
> > printers, Nas, cash register, 2 modems...)
> 
> No quarrel with the rest of your post, but I would do this with just
> one Ethernet interface on the router and then switches / hubs for
> everything else.
> 
Yep, at work I have a 24 port unmanaged switch,
but still use some ports on the router for dual Wan
(as single Wan could be very unreliable here) and
the other ports as a fallback should the switch
go belly up (lightning and spikes in Voltage happen also often)
at home I need to reduce the number of boxes (have a lot...,
like to tinker) so router and switch all in one is a good thing
and leaves more place for my wife's books in the shelves ;-)

Ciao,
Tito
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Ian Zimmerman]

On 2020-12-18 21:28, tito via Dng wrote:

> I love physical connections therefore I prefer NICs over Wifi, so 12
> of them are not so much (a few clients, a server, pos, couple of
> printers, Nas, cash register, 2 modems...)

No quarrel with the rest of your post, but I would do this with just one
Ethernet interface on the router and then switches / hubs for everything
else.

-- 
Ian
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi,

On 19/12/20 15:22, tito via Dng wrote:

is this a database generated at runtime about the devices of the
current machine or just a collection of hardware ids/info?
In the latter case couldn't we let the udev/systemd people do the
work and use their database?


It's the second one.

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Sat, 19 Dec 2020 15:10:01 +0100
Didier Kryn  wrote:

> Le 18/12/2020 à 17:26, Hendrik Boom a écrit :
> >
> > https://wiki.gentoo.org/wiki/Mdev says:
> >  In general, when using KDE or GNOME, mdev is not suitable.
> > but does not explain why.
> > I surmise that KDE and GNOME have some specific involvement with
> > udev.
> >
>     AFAIU, Xorg uses libudev to retrieve information on devices. This
> can be worked around by providing Xorg with config files like in the
> old times, which is kind of a pain. This is the only thing which held
> me back from switching to Mdev a few years ago.
> 
> 
> Le 18/12/2020 à 20:25, aitor a écrit :
> 
> > On 18/12/20 20:03, Joel Roth via Dng wrote:
> >
> >> And what about Jude Nelson's vdev? I, for one, would donate
> >> to support development of these lightweight udev alternatives.
> > Last lime i built vdev was at the very beginning of 2019 under
> > devuan testing (beowulf) before the conferences.
> > And It worked after doing some minor changes in the code. Maybe i
> > can recover this work.
> 
>     I have followed the development of Vdev by Jude Nelson, but, at
> some point, I got frightened by the forest (dozens) of shell scrips
> which implemented the actions to perform when devices were
> installed/removed.
> 
>     I think that, like in the case of Mdev, the biggest difficulty is
> in emulating libudev, which requires in particular to maintain an
> up-to-date database of devices. Jude has done a complete job and
> libvdev provides this emulation, but who maintains the database ?
Hi,
is this a database generated at runtime about the devices of the
current machine or just a collection of hardware ids/info?
In the latter case couldn't we let the udev/systemd people do the
work and use their database? 

Ciao,
Tito

>     Another issue with emulating libudev is that it implies to
> continuously run after Udev and Systemd. I lean to think it would be
> nicer to have a simpler and stable API. Though I confess I have none
> in mind (~:
> 
>     Cheers.
> 
> --         Didier
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Didier Kryn]

Le 18/12/2020 à 17:26, Hendrik Boom a écrit :
>
> https://wiki.gentoo.org/wiki/Mdev says:
>  In general, when using KDE or GNOME, mdev is not suitable.
> but does not explain why.
> I surmise that KDE and GNOME have some specific involvement with udev.
>
    AFAIU, Xorg uses libudev to retrieve information on devices. This
can be worked around by providing Xorg with config files like in the old
times, which is kind of a pain. This is the only thing which held me
back from switching to Mdev a few years ago.


Le 18/12/2020 à 20:25, aitor a écrit :

> On 18/12/20 20:03, Joel Roth via Dng wrote:
>
>> And what about Jude Nelson's vdev? I, for one, would donate
>> to support development of these lightweight udev alternatives.
> Last lime i built vdev was at the very beginning of 2019 under devuan
> testing (beowulf) before the conferences.
> And It worked after doing some minor changes in the code. Maybe i can
> recover this work.

    I have followed the development of Vdev by Jude Nelson, but, at some
point, I got frightened by the forest (dozens) of shell scrips which
implemented the actions to perform when devices were installed/removed.

    I think that, like in the case of Mdev, the biggest difficulty is in
emulating libudev, which requires in particular to maintain an
up-to-date database of devices. Jude has done a complete job and libvdev
provides this emulation, but who maintains the database ?

    Another issue with emulating libudev is that it implies to
continuously run after Udev and Systemd. I lean to think it would be
nicer to have a simpler and stable API. Though I confess I have none in
mind (~:

    Cheers.

--         Didier



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Fri, 18 Dec 2020 18:55:22 +0100
Antony Stone  wrote:

> On Friday 18 December 2020 at 00:17:48, tito via Dng wrote:
> 
> > Hi,
> > a few days ago I was able to complete may new router
> > with 12 nics and 1 wifi.
> 
> I'm intrigued.  What do you need 12 NICs for these days?
> (I say "these days" because (a) so many things are wireless now and
> don't use cables, and (b) VLANs are so easy to configure.)
> 
> Many years ago I built machines with up to 20 NICs in them, but those
> were routers for buildings with many small companies in them, and
> only one Internet connection.  These days everyone has their own DSL.
> 
> 
> Thanks,
> 
> 
> Antony.
> 

Hi,
I just am fed up with the usual commercial wifi routers,
most of them are crap, bug and vulnerability ridden
and after a couple of updates the manufacturer forgets
about them.
My first ISP DSL-Modem-router at work was never updated in
years, so the only chance to have something that is updated 
is to use x86 and debian/devuan. Once it is setup it works
for years. At work usually I buy second hand security
appliances like the Sophos UTM-425 or Lanner stuff,
change the fans with some more silent ones and put
Devuan on them rather than pay the horrendous licenses
to get basically the same.
I love physical connections therefore I prefer NICs over Wifi,
so 12 of them are not so much (a few clients, a server, pos,
couple of printers, Nas, cash register, 2 modems...)
and you have just one entry point which is easier to defend
from intrusion. At  home I needed to build the box because
servers don't fit on shelves. I used a nice short depth case,
a Jetway NF592-Q170 board (8nics) and a quadport card
+ a alpha networks minipcie wifi card. Works like a charm.
It allows me to test at home stuff before I deploy it at work
and gives me some freedom as I run my own cloud with
calendar and address book, adblocking and dns..
and I like to tinker!!!
That's why I love Devuan because Debian by adding
unneeded complexity wants to deprive me of the 
power of doing things by myself and understanding how 
they work.

Ciao,
Tito
 

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi,

On 18/12/20 19:14, d...@d404.nl wrote:
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.



You can change this flag in debian/rules:

CONFFLAGS = \
    --exec-prefix= \
    --with-rootprefix= \
    --with-rootlibdir=/lib/$(DEB_HOST_MULTIARCH) \
    --disable-silent-rules \
    --enable-rule-generator

HTH,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[aitor]

Hi Joel,

On 18/12/20 20:03, Joel Roth via Dng wrote:

On Fri, Dec 18, 2020, Didier Kryn wrote:

     Shouldn't we consider using Mdev instead of Eudev? You, as a
distinguished contributor to Busybox, should have an opinion on this.

And what about Jude Nelson's vdev? I, for one, would donate
to support development of these lightweight udev alternatives.
Last lime i built vdev was at the very beginning of 2019 under devuan 
testing (beowulf) before the conferences.
And It worked after doing some minor changes in the code. Maybe i can 
recover this work.


Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Joel Roth via Dng]

On Fri, Dec 18, 2020, Didier Kryn wrote:
>     Shouldn't we consider using Mdev instead of Eudev? You, as a
> distinguished contributor to Busybox, should have an opinion on this.

And what about Jude Nelson's vdev? I, for one, would donate
to support development of these lightweight udev alternatives. 

-- 
Joel Roth
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[d...@d404.nl]

On 18-12-2020 14:41, tito via Dng wrote:
> On Fri, 18 Dec 2020 10:36:01 +0100
> Didier 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@lists.dyne.org
> 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], 

Re: [DNG] if2mac init.d service for persistent network interface names

[Antony Stone]

On Friday 18 December 2020 at 00:17:48, tito via Dng wrote:

> Hi,
> a few days ago I was able to complete may new router
> with 12 nics and 1 wifi.

I'm intrigued.  What do you need 12 NICs for these days?

(I say "these days" because (a) so many things are wireless now and don't use 
cables, and (b) VLANs are so easy to configure.)

Many years ago I built machines with up to 20 NICs in them, but those were 
routers for buildings with many small companies in them, and only one Internet 
connection.  These days everyone has their own DSL.


Thanks,


Antony.

-- 
GIT/E d- s+:--(-) a+ C$(---) UL$ P+(---)>++ L+++()$ !E W(-) N(-) 
o? w--(---) O !M V+++(--) !PS !PE Y+ PGP+> t- !tv@ b+++ DI++ D--- e+++(*) h++ 
5? !X- !R K--? G-

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Hendrik Boom]

On Fri, Dec 18, 2020 at 03:53:11PM +0100, tito via Dng wrote:
> Hi,
> to be honest I have no opinion on it because I never looked at the code
> (last time I touched something similar it was devfsd which I shrinked
> in a ugly way for bb) and it would be a cold dive anyway.
> Does mdev have all needed features to replace udev/eudev?
> I'm for sticking as close as possible to debian (until they are
> enlightenedcentos' end should be a lesson to them) to reduce the
> fallout of the changes and because the devuan manpower is limited.
> Minor non invasive modifications  like if2mac script give you back the
> desired functionality without interfering with the internals.

https://wiki.gentoo.org/wiki/Mdev says:
 In general, when using KDE or GNOME, mdev is not suitable.
but does not explain why.
I surmise that KDE and GNOME have some specific involvement with udev.

-- hendrik

> 
> Ciao,
> Tito 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Fri, 18 Dec 2020 15:22:37 +0100
Didier Kryn  wrote:

> Le 18/12/2020 à 14:41, tito via Dng a écrit :
> > On Fri, 18 Dec 2020 10:36:01 +0100
> > Didier 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.
> >
>     Shouldn't we consider using Mdev instead of Eudev? You, as a
> distinguished contributor to Busybox, should have an opinion on this.
> 
> --         Didier
> 
Hi,
to be honest I have no opinion on it because I never looked at the code
(last time I touched something similar it was devfsd which I 

Re: [DNG] if2mac init.d service for persistent network interface names

[Didier Kryn]

Le 18/12/2020 à 14:41, tito via Dng a écrit :
> On Fri, 18 Dec 2020 10:36:01 +0100
> Didier 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.
>
    Shouldn't we consider using Mdev instead of Eudev? You, as a
distinguished contributor to Busybox, should have an opinion on this.

--         Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[tito via Dng]

On Fri, 18 Dec 2020 10:36:01 +0100
Didier 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@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] if2mac init.d service for persistent network interface names

[Didier Kryn]

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



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng