systemd-networkd loses connection on router reset

moose jaw · 2021-02-09 06:02:59

I have a headless box using systemd-networkd to control a wired ethernet connection, getting its address via DHCP from my ISP router. When the router resets itself (happening more and more, because it's old), after the connection comes back the Arch box running systemd-networkd fails to reconnect to the router, and is unreachable on my local network. I have to power cycle the box to get it back online.

journalctl isn't showing any useful output that I can see. Does anyone know how to get systemd-networkd to reconnect automatically when the router resets itself?

Koatao · 2021-02-09 08:03:30

Hello,

What is your .network (and if so your .link) configuration files for the wired network interface?

With this config, it should reconnect correctly.

moose jaw wrote:

journalctl isn't showing any useful output that I can see.

Post it anyway, maybe someone else can find something useful. I guess only posting the part beginning when your ISP router goes down is enough.

moose jaw wrote:

the Arch box running systemd-networkd fails to reconnect to the router

How do you know that it fails to reconnect to the router? What does that mean? Carrier is lost?
After your ISP router is restarted, does your arch box gets a new DHCP lease?

Without your arch box connected to the network, you cannot connect to it by any others ways?

Last edited by Koatao (2021-02-09 08:04:37)

moose jaw · 2021-02-09 16:16:36

Thanks for your reply. The .network file is exactly as on the wiki. There is no journalctl output for approximately a day between the last successful ssh disconnect and when I had to power cycle the box. Here is what immediately precedes the subsequent boot:

Feb 07 22:55:09 mpdpi systemd[7070]: Stopped target Main User Target.
Feb 07 22:55:09 mpdpi systemd[7070]: Stopped target Basic System.
Feb 07 22:55:09 mpdpi systemd[7070]: Stopped target Paths.
Feb 07 22:55:09 mpdpi systemd[7070]: Stopped target Sockets.
Feb 07 22:55:09 mpdpi systemd[7070]: Stopped target Timers.
Feb 07 22:55:09 mpdpi systemd[7070]: dbus.socket: Succeeded.
Feb 07 22:55:09 mpdpi systemd[7070]: Closed D-Bus User Message Bus Socket.
Feb 07 22:55:09 mpdpi systemd[7070]: dirmngr.socket: Succeeded.
Feb 07 22:55:09 mpdpi systemd[7070]: Closed GnuPG network certificate management daemon.
Feb 07 22:55:09 mpdpi systemd[7070]: gpg-agent-browser.socket: Succeeded.
Feb 07 22:55:09 mpdpi systemd[7070]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Feb 07 22:55:09 mpdpi systemd[7070]: gpg-agent-extra.socket: Succeeded.
Feb 07 22:55:09 mpdpi systemd[7070]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Feb 07 22:55:09 mpdpi systemd[7070]: gpg-agent-ssh.socket: Succeeded.
Feb 07 22:55:09 mpdpi systemd[7070]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Feb 07 22:55:09 mpdpi systemd[7070]: gpg-agent.socket: Succeeded.
Feb 07 22:55:09 mpdpi systemd[7070]: Closed GnuPG cryptographic agent and passphrase cache.
Feb 07 22:55:09 mpdpi systemd[7070]: p11-kit-server.socket: Succeeded.
Feb 07 22:55:09 mpdpi systemd[7070]: Closed p11-kit server.
Feb 07 22:55:09 mpdpi systemd[7070]: Removed slice User Application Slice.
Feb 07 22:55:09 mpdpi systemd[7070]: Reached target Shutdown.
Feb 07 22:55:09 mpdpi systemd[7070]: systemd-exit.service: Succeeded.
Feb 07 22:55:09 mpdpi systemd[7070]: Finished Exit the Session.
Feb 07 22:55:09 mpdpi systemd[7070]: Reached target Exit the Session.
-- Boot 0df056df5af64caa94ea4b19da9cfa82 --
Feb 08 23:34:58 mpdpi systemd[241]: Queued start job for default target Main User Target.

When I say that it fails to reconnect to the router, what I mean is that attempting to ssh into the box gives a "no route to host" error. I suppose conceivably this could be an sshd problem instead of a systemd-networkd problem.

Last edited by moose jaw (2021-02-09 16:18:03)

mcloaked · 2021-02-09 17:26:00

When you attempt to ssh to the box is it via ip address or via hostname? If neither work, then perhaps one option is to run a cron job that will restart the network daemons periodically if a ping test to some box elsewhere fails (as a script)? At least that way you may be able to get some logged diagnostics without the need to power cycle the box?

Last edited by mcloaked (2021-02-09 17:26:50)

Koatao · 2021-02-09 17:45:13

moose jaw wrote:

When I say that it fails to reconnect to the router, what I mean is that attempting to ssh into the box gives a "no route to host" error. I suppose conceivably this could be an sshd problem instead of a systemd-networkd problem.

No it is not a sshd problem (there is no way rebooting your router would impact sshd on the Arch host directly). "No route to host" is indeed valuable information.

I think your Arch box doesn't get you rebooted your ISP router. If systemd-networkd doesn't detect that the interface lost carrier, it will not reconfigure the interface and leave it as it is.

Thing is, your ISP router has probably no clue the Arch host exists on the network.

Did you try only unplugging and replugging the network cable? (so that systemd-networkd detect that the carrier is lost for a moment and reconfigure the interface with DHCP automatically).

Is your Arch host directly connected to the router or is there a switch?

moose jaw · 2021-02-10 04:36:26

@mcloaked, thank you for the suggestion, that may be a good workaround.

@Koatao: The Arch box is connected to the ISP router directly via ethernet, and gets its IP address from the router via DHCP. When the router resets itself, everything on the network needs to get back online. I have a wifi router running in bridge mode that's connected to the ISP router via ethernet, and everything on the wifi network successfully reconnects (getting an address via DHCP from the ISP router) after one of these incidents. That includes an Arch laptop running NetworkManager. I also have a Roku streaming box connected to the ISP router via ethernet, and it gets back online successfully. It's only my headless Arch box connected via ethernet, running the systemd network tools, that fails to reconnect.

moose jaw · 2021-02-10 04:43:56

Another possibility is that it's not a systemd network tools issue, but rather a hardware issue. When the "no route to host" issue arises, the ethernet LEDs are totally dark, and don't light up again until a power cycle. This is a Raspberry Pi that's probably 6 or 7 years old at this point. It may be time to replace it.

jasonwryan · 2021-02-10 05:17:32

moose jaw wrote:

This is a Raspberry Pi that's probably 6 or 7 years old at this point. It may be time to replace it.

So, not an Arch issue at all... Arch ARM is a separate distribution, please ask on their boards: https://bbs.archlinux.org/viewtopic.php?id=153431

moose jaw · 2021-02-10 18:42:31

Ok, I have opened a thread there. I'm aware they are different distros but thought perhaps the systemd-networkd issue might be a more general one that might also affect Arch proper, and where the larger user community might have insight to offer.

In any case, the new thread (with some new info) is here for anyone interested: https://archlinuxarm.org/forum/viewtopi … 57&t=15118

Arch Linux

#1 2021-02-09 06:02:59

systemd-networkd loses connection on router reset

#2 2021-02-09 08:03:30

Re: systemd-networkd loses connection on router reset

#3 2021-02-09 16:16:36

Re: systemd-networkd loses connection on router reset

#4 2021-02-09 17:26:00

Re: systemd-networkd loses connection on router reset

#5 2021-02-09 17:45:13

Re: systemd-networkd loses connection on router reset

#6 2021-02-10 04:36:26

Re: systemd-networkd loses connection on router reset

#7 2021-02-10 04:43:56

Re: systemd-networkd loses connection on router reset

#8 2021-02-10 05:17:32

Re: systemd-networkd loses connection on router reset

#9 2021-02-10 18:42:31

Re: systemd-networkd loses connection on router reset

Board footer