It is a good clear article.
It is about the Debian ifupdown package which sets up configurations in /etc/network/interfaces but unfortunately it does not deal with naming
I have the package ifupdown-ng installed in Artix and I use it to deal with the statically configured local net interface, which I blacklist in connman.
I let connman configure the modem dhcp interface , so that it becomes the default route. That all works well… until Artix boots and changes the interface names.
My understanding was that Predictable Naming should take care of that. It’s also why I can’t just use eth0 and eth1 for a network connection anymore. I don’t know if that is specific to systemd or not.
I found a forum post on the topic for Artix.
I didn’t read all the way through it though. Hopefully it’s useful.
Thanks, it is useful because it explains
I now know
the kernel sets the etho, eth1 type of names, and it can be told not to with a kernel boot parameter. These names are not persistent
udev (or at least some varieties of udev) overrides what the kernel sets , using a udev rule , to names like enp2s0 and these names are persistent
there is a utility ifrename which can be used to override all of the above and set names based on for example the NIC’s mac address, and they would be persistent because the mac address is immutable.
it is possible to use systemd for namesetting, but that is not an option in Artix
it would seem Artix used to have persistent names but they disappeared after some update to udev.
One has to ask, why not get it right in the kernel in the first place?
go to /etc/udev/rules.d.
there is a files 80-net-name-slot.rules
which is a link to /dev/null
Remove the link, and make a file 80-net-name-slot.rules
containing the rules file from @pdecker 's link
# do not edit this file, it will be overwritten on update
ACTION!="add", GOTO="net_name_slot_end"
SUBSYSTEM!="net", GOTO="net_name_slot_end"
NAME!="", GOTO="net_name_slot_end"
IMPORT{cmdline}="net.ifnames"
ENV{net.ifnames}=="0", GOTO="net_name_slot_end"
NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}"
NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"
LABEL="net_name_slot_end"
go to /etc/default and edit the file grub changing the line GRUB_CMDLINE_LINUX="net.ifnames=0"
to GRUB_CMDLINE_LINUX="net.ifnames=1"
Do update-grub in Artix to make a new grub.cfg file
Boot into Void and do update-grub in Void so that the grub menu entry for Artix sees the new grub.cfg file in Artix.
Reboot Artix and I get the persistent interface names
enp17s0 is my local net
eno1 is my internet link
go to /etc/network and edit the interfaces file to use persistent names
I have eno1 commented out because I am going to let connman control it
go to /etc/connman and edit the file main.conf
NetworkInterfaceBlacklist = enp17s0
Fix that one line to use persistent name.
That stops connman trying to configure the static IP of the local net.
Reboot Artix and things seem to be OK, but
Connman is still making 2 default routes… it has some memory of the
blacklisted local net.
I get rid of that by
Then I have only one default route, and the internet works
but I still cant ping anything on the local net
I can bring it up with ifup -a
then it works.
So I think it is right, but I may yet have to abandon connman altogether and let ifupdown control both NIC’s.
Not quite.
Connman is still trying to control the Blacklisted enp17s0 interface
I had to go to /var/lib/connman
where connman stores its settings, and delete the directory ethernet_c86000cb0b6c_cable
to get rid of connman’s memory of trying to control the static interface… it was ignoring the Blacklist and still listing it as a service!!!
Well then it almost works, except the enp17s0 connection comes with its static IP configured but in the DOWN state ?
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: enp17s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether c8:60:00:cb:0b:6c brd ff:ff:ff:ff:ff:ff
I have to do ifup -a to get
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: enp17s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c8:60:00:cb:0b:6c brd ff:ff:ff:ff:ff:ff
inet 192.168.32.6/11 scope global enp17s0
valid_lft forever preferred_lft forever
inet6 fe80::ca60:ff:fecb:b6c/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
and then I can ping the printer.
So, last question, why is ifupdown not implementing the auto command in its /etc/network/interfaces file?
#auto lo
#iface lo inet loopback
#wired-local network
auto enp17s0
iface enp17s0
address 192.168.32.6
netmask 255.225.255.0
#wired-modem network
#auto eno1
#iface eno1 inet dhcp
#iface eno1 inet6 auto
auto enp17s0 is supposed to automatically bring up the interface?
at least it always does so in Debian with ifupdown… Artix with ifupdown-ng may be different?
The manual says
“auto object
Designates that object should be automatically configured by the
system when appropriate.”
So it only says ‘configured’ not ‘brought up’
Maybe that is what it is meant to do?
Well I thought I had it solved, but connman keeps grabbing control of both interfaces and making 2 default routes.
I think I have to disable connman and use ifupdown for both.
auto lo
iface lo inet loopback
#wired-local network
auto enp17s0
iface enp17s0
address 192.168.32.6
netmask 255.225.255.0
#wired-modem network
auto eno1
iface eno1 inet dhcp
iface eno1 inet6 auto
Then reboot and I get no routes at all
trinity:[nevj]:/etc/network$ ip r
trinity:[nevj]:/etc/network$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: enp17s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether c8:60:00:cb:0b:6c brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether c8:60:00:cb:0e:28 brd ff:ff:ff:ff:ff:ff
4: wlp15s0: <BROADCAST,MULTICAST,DYNAMIC> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:08:ca:33:d4:47 brd ff:ff:ff:ff:ff:ff
They are all DOWN.
So
# ifup -a
dhcpcd-10.1.0 starting
eno1: waiting for carrier
eno1: carrier acquired
DUID 00:01:00:01:2e:dd:73:a9:c8:60:00:cb:0e:28
eno1: IAID 00:cb:0e:28
eno1: adding address fe80::dc61:d5b6:1050:ea87
eno1: soliciting a DHCP lease
eno1: soliciting an IPv6 router
eno1: Router Advertisement from fe80::d692:5eff:fe20:8816
eno1: adding address 2001:8003:2c09:f600:ab56:8c05:5b70:8e4e/64
eno1: adding route to 2001:8003:2c09:f600::/56 via fe80::d692:5eff:fe20:8816
eno1: adding route to 2001:8003:2c09:f600::/64
eno1: adding default route via fe80::d692:5eff:fe20:8816
eno1: requesting DHCPv6 information
eno1: REPLY6 received from fe80::d692:5eff:fe20:8816
eno1: refresh in 600 seconds
That is interesting, it starts dhcpcd
That may be why they do not come up automatically… dhcpcd is not running?
Then all the routes appear
$ ip r
default via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.58 metric 1003
192.160.0.0/11 dev enp17s0 proto kernel scope link src 192.168.32.6
192.168.0.0/24 dev eno1 proto dhcp scope link src 192.168.0.58 metric 1003
and all the interfaces are up
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: enp17s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c8:60:00:cb:0b:6c brd ff:ff:ff:ff:ff:ff
inet 192.168.32.6/11 scope global enp17s0
valid_lft forever preferred_lft forever
inet6 fe80::ca60:ff:fecb:b6c/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c8:60:00:cb:0e:28 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.58/24 brd 192.168.0.255 scope global dynamic noprefixroute eno1
valid_lft 86389sec preferred_lft 75589sec
inet6 2001:8003:2c09:f600:ab56:8c05:5b70:8e4e/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 69376sec preferred_lft 69376sec
inet6 fe80::dc61:d5b6:1050:ea87/64 scope link
valid_lft forever preferred_lft forever
4: wlp15s0: <BROADCAST,MULTICAST,DYNAMIC> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:08:ca:33:d4:47 brd ff:ff:ff:ff:ff:ff
Now that seems to have solved it, except
trinity:[root]:/var/lib/connman# ls
ethernet_c86000cb0b6c_cable settings
connman still thinks it has to control the local ethernet, even though it is blacklisted.
I think connman does not understand the enp17s0 persistent interface name
So I had to manually take connmand out of s6’s default bundle, and put dhcpcd into the default bundle, and rebuild the database.
S6 is not the easiest init system, by a long way.
Then reboot and I get
$ ip r
default via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.58 metric 1003
192.168.0.0/24 dev eno1 proto dhcp scope link src 192.168.0.58 metric 1003
that is fine, and
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: enp17s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c8:60:00:cb:0b:6c brd ff:ff:ff:ff:ff:ff
inet6 fe80::eccb:2b55:14e9:ae24/64 scope link
valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c8:60:00:cb:0e:28 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.58/24 brd 192.168.0.255 scope global dynamic noprefixroute eno1
valid_lft 86364sec preferred_lft 75564sec
inet6 2001:8003:2c09:f600:ab56:8c05:5b70:8e4e/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 58729sec preferred_lft 58729sec
inet6 fe80::dc61:d5b6:1050:ea87/64 scope link
valid_lft forever preferred_lft forever
4: wlp15s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 00:08:ca:33:d4:47 brd ff:ff:ff:ff:ff:ff
that is not OK… the enp17s0 interface is UP and it has an inet6 entry but no IPv4 entry ???
I still need to use ifup -a
I dont get it , why is the static interface not being configured right?
It only depends on /etc/network/interfaces
auto lo
iface lo inet loopback
#wired-local network
auto enp17s0
iface enp17s0
address 192.168.32.6
netmask 255.225.255.0
#wired-modem network
auto eno1
iface eno1 inet dhcp
iface eno1 inet6 auto
It sure seems harder than it should be. I thought you had it beat by seizing manual control. Sometimes these things that try to make something easier by doing it automatically get part of it either wrong or just not what you would prefer. Then make it harder than the original task was to get around. Ugh.
Based on Arch Linux, Obarun provides not only a reliable alternative but a service management experience like no other, tailored to give professionals total control.
It is now even harder
I decided to abandon idupdown ( /etc/network interfaces) and try to configure the local net with dhcpcd, so
in dhcpcd.conf I added the lines
#local net with static IP
ipv4 enp17s0
interface enp17s0
nogateway
static 192.168.32.6/24
and the enp17s0 interface then comes up exactly the same as I get with /etc/network interfaces enables, ie
2: enp17s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c8:60:00:cb:0b:6c brd ff:ff:ff:ff:ff:ff
inet6 fe80::eccb:2b55:14e9:ae24/64 scope link
valid_lft forever preferred_lft forever
Both dhcpcd and ifupdown are making an ipv6 (inet6) link ???
and
When I enable /etc/network iterfaces and bring enp17s0 up with ifup enp17s0
I get
2: enp17s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c8:60:00:cb:0b:6c brd ff:ff:ff:ff:ff:ff
inet 192.168.32.6/24 scope global enp17s0
valid_lft forever preferred_lft forever
inet6 fe80::eccb:2b55:14e9:ae24/64 scope link
valid_lft forever preferred_lft forever
which is right, and it works, but the inet6 link is still there?
I feel now that because dhcpcd has the same problem as ifupdown and connman, the problem is likely not in these configuration tools.
I think the problem may be in the interface renaming that was done using a udev rule. There is something strange about enp17s0?
I also dont understand why ifup enp17s0 can force it to configure but it does not configure on boot?
It may be a question of the timing of things during boot, so the culprit may be S6 or the ordering of udev rules. The interface needs to be renamed before it can be configured, but if that is the problem why was eno1 not affected?
Wrong there.
I had an error in the dhcpcd.conf file which caused it to not configure the enp17s0 interface.
If I disable ifupdown ( ie remove the /etc/network/interfaces file) and configure dhcpcd properly, it works.
Here are my correct /etc/dhcpcd.conf settings
allowinterfaces ???????,??????,?????,????
# local net with static IP
ipv4 enp17s0
interface enp17s0
ipv4only
nogateway
static ip_address=192.168.32.6/24
I needed that pattern matching allowinterfaces statement to get it to accept a 7 character interface name
I had static 192.168.32.6/24 which was wrong… that notation belongs to ifupdown, dhcpcd is different.
The nogateway statement stops dhcpcd making a default route for the interface
Conclusion:
dhcpcd can deal with long persistent interface names
ifupdown-ng seems not to be able to bring up a static interface automatically, but it can do it manually with the ifup -a command
connman seems not to be able to deal with 2 ethernet interfaces without wanting to make them both default routes.
there is nothing wrong with Artix or S6…the problems were in connman and ifupdown-ng.
So clearly dhcpcd is the superior networking package. … the solution is to use dhcpcd (properly configured)
and
I learnt something about the original question of this topic… It is possible to have persistent interface names and to keep the old style ( eth0, eth1,…) names. To do that install 80-net-name-slot.rules in /etc/udev/rules.d and set the kernel boot parameter GRUB_CMDLINE_LINUX="net.ifnames=0"
instead of GRUB_CMDLINE_LINUX="net.ifnames=1"
That is what Antix does… it works fine.
Thank you to all for tolerating my bumbling efforts
