[SOLVED] Starting with eth0 down

Roken · 2022-12-18 16:05:50

This will sound weird, but I want Arch to start with only wireless connected, and not ethernet. Before anyone suggests just unplugging the cable, it's not an option.

I have my laptop tucked away between a bookcase and my desk. It starts from a magic packet when my main (desktop) machine boots (hence I need the ethernet connection), and is controlled via synergy from my desktop. The laptop is plugged in to an external monitor.

The laptop ethernet port is limited to 100Mbs. Speedtests demonstrate consistently that my wireless achieves more than double the throughput.

I've tried disabling the dhcpcd.service and enabling dhcpcd@wlan0.service, but is makes no difference. The ethernet still comes up on boot, and is used as default.

I use iwd for the wireless connection, and have removed networkmanager, so I'm not sure what is starting the interface.

As a workaround for now I've written a script which is run on login that takes eth0 down (or puts it up, if I so desire), but I'm sure that there must be a cleaner way.

Last edited by Roken (2022-12-18 20:27:38)

Head_on_a_Stick · 2022-12-18 17:12:04

Please post

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

-thc · 2022-12-18 17:16:39

Roken wrote:

I use iwd for the wireless connection, and have removed networkmanager, so I'm not sure what is starting the interface.

AFAIK from my own experience (starting with Arch years ago) Ethernet doesn't start by itself. There has to be some kind of network management.

Try

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

Roken · 2022-12-18 19:09:16

Thank you for helping.

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
avahi-daemon.service                     | multi-user.target.wants
avahi-daemon.socket                      | sockets.target.wants
bluetooth.service                        | bluetooth.target.wants
cups.path                                | multi-user.target.wants
cups.service                             | printer.target.wants
cups.socket                              | sockets.target.wants
dbus-org.bluez.service                   | system
dbus-org.freedesktop.Avahi.service       | system
dbus-org.freedesktop.timesync1.service   | system
dhcpcd.service                           | multi-user.target.wants
display-manager.service                  | system
fstrim.timer                             | timers.target.wants
getty@tty1.service                       | getty.target.wants
iwd.service                              | multi-user.target.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire-media-session.service           | pipewire.service.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
pulseaudio.socket                        | sockets.target.wants
reflector.service                        | multi-user.target.wants
remote-fs.target                         | multi-user.target.wants
sshd.service                             | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants
wol@eth0.service                         | multi-user.target.wants

Nothing stands out to me, but I'm not a network guru. EDIT: Hmm, just notice dhcpcd is still starting on all interfaces. Let me try and fix that again.

Last edited by Roken (2022-12-18 19:11:59)

Head_on_a_Stick · 2022-12-18 19:17:02

dhcpcd.service will act on all interfaces. Use the dhcpcd@.service instead to specifically activate only for the wireless connection.

EDIT: for clarity:

# systemctl disable --now dhcpcd
# systemctl enable --now dhcpcd@wlan0 # or whatever the interface is called

EDIT2: you claim to have already tried this but let's try again, just to be sure. If it doesn't work post the find command output again.

Last edited by Head_on_a_Stick (2022-12-18 19:19:41)

Roken · 2022-12-18 19:44:31

I've lost all networking now, until I fix from the local machine - give me a few minutes

Roken · 2022-12-18 19:59:35

OK - I'm back to where I was originally (i.e. before my script to take eth0 down).

If I disable dhcpcd and enable dhcpcd@wlan0.service (I need to add ".service", otherwise it appends ".com" I get no network at all, it simply times out.

For info, I am using the correct (legacy) interface names.

ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 98:e7:f4:59:e1:d4 brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 84:ef:18:26:49:36 brd ff:ff:ff:ff:ff:ff

Reverting to just dhcpcd brings all interfaces back. I could re-enable my script, but I'd rather not hack it.

This is the latest "find" command. Without a network, I can't post when all networks fail.

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
avahi-daemon.service                     | multi-user.target.wants
avahi-daemon.socket                      | sockets.target.wants
bluetooth.service                        | bluetooth.target.wants
cups.path                                | multi-user.target.wants
cups.service                             | printer.target.wants
cups.socket                              | sockets.target.wants
dbus-org.bluez.service                   | system
dbus-org.freedesktop.Avahi.service       | system
dbus-org.freedesktop.timesync1.service   | system
dhcpcd.service                           | multi-user.target.wants
display-manager.service                  | system
fstrim.timer                             | timers.target.wants
getty@tty1.service                       | getty.target.wants
iwd.service                              | multi-user.target.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire-media-session.service           | pipewire.service.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
pulseaudio.socket                        | sockets.target.wants
reflector.service                        | multi-user.target.wants
remote-fs.target                         | multi-user.target.wants
sshd.service                             | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants
wol@eth0.service                         | multi-user.target.wants

Oh - I suppose I could re-direct to a file then bring the network back up. Give me a mo.

Roken · 2022-12-18 20:07:29

This is a cold boot, with dhcpcd@wlan0.service enabled.

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
avahi-daemon.service                     | multi-user.target.wants
avahi-daemon.socket                      | sockets.target.wants
bluetooth.service                        | bluetooth.target.wants
cups.path                                | multi-user.target.wants
cups.service                             | printer.target.wants
cups.socket                              | sockets.target.wants
dbus-org.bluez.service                   | system
dbus-org.freedesktop.Avahi.service       | system
dbus-org.freedesktop.timesync1.service   | system
dhcpcd@wlan0.service                     | multi-user.target.wants
display-manager.service                  | system
fstrim.timer                             | timers.target.wants
getty@tty1.service                       | getty.target.wants
iwd.service                              | multi-user.target.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire-media-session.service           | pipewire.service.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
pulseaudio.socket                        | sockets.target.wants
reflector.service                        | multi-user.target.wants
remote-fs.target                         | multi-user.target.wants
sshd.service                             | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants
wol@eth0.service                         | multi-user.target.wants

And ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 98:e7:f4:59:e1:d4 brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 84:ef:18:26:49:36 brd ff:ff:ff:ff:ff:ff

What does "UP mode DORMANT" mean? I've never seen that before.

seth · 2022-12-18 20:22:11

The the chip is currently not doing anything, it doesn't indicate a problem.

ip a; ip r; systemctl status iwd

ftr, iwd can also configure the network itself: https://wiki.archlinux.org/title/Iwd#En … figuration

If you ab·so·lu·te·ly don't want to use the rj45 connection, you could also blacklist the relevant kernel module, but I'd focus on ignoring it in your network config for now.

Roken · 2022-12-18 20:27:21

@seth - thank you. Modifying iwd and disabling dhcpcd completely got me to where I want to be.

Marking as solved.

seth · 2022-12-18 20:39:13

I'd still suggest to some day look at the system journal for the dhcpcd@wlan0 failures as they might be symptoms for a different issue.
(dhcpcd should™ wait until the NIC gets a carrier, which is then provided by iwd, and at that point obtain a lease)

Roken · 2022-12-18 21:25:49

I did check journalctl, but apart from saying that it timed out, there was nothing to offer any clue

seth · 2022-12-19 04:48:29

iwd takes toolong™?
https://wiki.archlinux.org/title/Dhcpcd#Timeout_delay

Arch Linux

#1 2022-12-18 16:05:50

[SOLVED] Starting with eth0 down

#2 2022-12-18 17:12:04

Re: [SOLVED] Starting with eth0 down

#3 2022-12-18 17:16:39

Re: [SOLVED] Starting with eth0 down

#4 2022-12-18 19:09:16

Re: [SOLVED] Starting with eth0 down

#5 2022-12-18 19:17:02

Re: [SOLVED] Starting with eth0 down

#6 2022-12-18 19:44:31

Re: [SOLVED] Starting with eth0 down

#7 2022-12-18 19:59:35

Re: [SOLVED] Starting with eth0 down

#8 2022-12-18 20:07:29

Re: [SOLVED] Starting with eth0 down

#9 2022-12-18 20:22:11

Re: [SOLVED] Starting with eth0 down

#10 2022-12-18 20:27:21

Re: [SOLVED] Starting with eth0 down

#11 2022-12-18 20:39:13

Re: [SOLVED] Starting with eth0 down

#12 2022-12-18 21:25:49

Re: [SOLVED] Starting with eth0 down

#13 2022-12-19 04:48:29

Re: [SOLVED] Starting with eth0 down

Board footer