eth network stuck at routable (configuring) #8686
Labels
bug 🐛
Programming errors, that need preferential fixing
needs-reporter-feedback ❓
There's an unanswered question, the reporter needs to answer
network
Comments
|
Seeing the same on Gentoo (~x86_64) with systemd-238... I feel like the network subsystem is getting routinely broken -- what's going on there? |
|
Can you please try with #9174 |
|
Did not observe any change after applying #9174. Will try to experiment more next week. |
|
I'm seeing a similar problem with |
|
This behaviour still present on Debian Sid using systemd 239-10 with a static IP. |
|
I believe I'm seeing this same issue, on systemd 239 on Debian testing. I'm not using Debian's /etc/network/interfaces at all, everything is managed by systemd-networkd (except ppp0 because networkd doesn't support PPPoE natively). I have a fairly complex network setup consisting of:
My As you can see, eno2 and rev-lifeline are stuck in Config files for the various interfaces follows.
Will try digging through the networkd code tomorrow to see if I can find something, but hopefully this is another datapoint to help experts isolate where the fault is. |
|
Please test the current git master. I've updated many places in networkd and wait-online after v241 is released. |
yuwata
added
the
needs-reporter-feedback ❓
|
Same with Manjaro (Arch) |
|
Tried to debug the same issue on ubuntu 18.04 where I configure static addresses. Found the clues from https://wiki.archlinux.org/index.php/IPv6#systemd-networkd_2 So in my case I have disabled ipv6 through sysctl and if I don't have the interface will remain in configuring state. Apparently due to disabling ipv6 globally I don't have to disable route advertisements explicitly. So this also made my |
|
@lassizci Such situation is hopefully already fixed. If possible, please test the current git master. Thank you. |
|
Is this still reproducible with the current git master? If so, please provide .network files and debugging logs. The debug log can be generated by e.g. creating the following drop-in config: |
|
I was able to fix the issue on our machines using @yuwata 's advice about enabling debugging. DHCPv6 was inadvertently turned on in systemd is 237-3ubuntu10.22 |
|
Has there been any further progress on this issue? I use IPv6, so disabling link-local addressing is not an option. And I do not use netplan. What is |
|
@tomc603 are you using DHCP6, RA, or static provisioning? |
|
@tomc603 it is waiting for at least one interface with operational-state up. See |
|
I use DHCPv6 RA, my clients are offered v6 DNS entries by RDNSS, and the v6 DNS servers use link-local addresses. Just in case that's important to debugging. I know it's waiting for an interface to become online, but the interfaces are fully functional. systemd 240 (240-6ubuntu5.7) |
|
@tomc603 As long as it says |
|
If you are using RA the interface will appear to work properly even if dchp client failed btw. The interface will use a RA address and not a dhcp6 address, but show as (configuring). |
|
DHCPv6 is working properly, since I receive an assignment from the prefix delegated to me. I'm able to fully utilize IPv6 and IPv4, so I can confirm v6 is working as expected. The bug I believed we were discussing in this thread was that If this is not the correct bug to discuss that behavior, then I'll search for that one instead. |
|
@tomc603 apologies for the misunderstanding. Yes, if it turns out that |
|
Note that in almost all of my mission critical systems I go out of my way to avoid all networking related stuff in systemd; almost all of it doesn't work right (e.g. the ridiculous DNS resolver proxy mess) |
|
I've found systemd-networkd and systemd-resolved to work very well, which is why I'd like to contribute to this issue being resolved. Thanks for your help, but I think I'd rather discuss the issue at hand with the maintainers. |
|
@tomc603 I'm sure you didn't mean offense, but you may be waiting for some time if you wish to rely exclusively on systemd devs. The maintainers have not given anyone any details whatsoever as to what the problem is, nor the steps they have taken to address it. This is all we got from them:
No commit message, no failure analysis, no details on possible root causes. Nothing. The bug remains open. |
|
@tomc603 Please provide .network files and debugging logs. |
|
|
@yuwata You misunderstand. The problem isn't reproducing any specific reason why an interface hangs in "configuring", much less fixing an issue which is, most likely, a configuration or server problem on the reporter's side. The problem is, plain and simple, that This is a general problem that exists in all systemd versions so far. Thus neither stating which systemd version I'm using, posting a specific network file, nor random debug logs can possibly help with fixing that. As soon as that deficiency is corrected, solving all these separate problems people have been reporting becomes trivial and reporting stuff like .network files and debug logs will become mostly unnecessary. I wouldn't need a debug log if networkctl told me that my DHCPv6 server doesn't answer. Without that information, I need to scratch my head, turn on debugging, restart networkd, notice I forgot to daemon-reload, restart networkd again, dig through the log, and then hopefully figure out what it's missing out on. That's a much higher time requirement and cognitive load than simply noticing a "waiting for DHCPv6 reply" line in |
|
@smurfix Thanks. Your suggestion makes sense. And, it is not hard to implement that, I think. But, could you open a new page to request such a feature? Otherwise, we can easily forget your suggestion. Note, you may already noticed, now networkd (NOT networkctl) reports why the interface is not in configured state in debug log. So, until such a new feature is implemented to networkctl, please use |
|
Same issue on Debian $ systemd --version
systemd 247 (247.3-5~bpo10+2)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybridNetwork configuration (this is a VLAN device) $ cat /etc/systemd/network/home.network
[Match]
Name=home
[Network]
DHCP=ipv4Debug logs |
|
@riobard IPv6 is disabled on your system? |
|
@yuwata That's the weird part. IPv6 is NOT disabled anywhere. Later today I accidentally rebooted the machine without changing anything, and now it seems to work fine. I've no idea why 😂 |
|
While trying to fix this issue myself today, I stumbled upon a strange procedure that seems to have resolved it for me. I'm posting it here in hopes that it may help someone else. Previously, my machine had two interfaces that were stuck in the The procedure that I discovered has three steps:
A few seconds after using these steps on each of my interfaces, they finally reached the |
|
I get the same issue on arch linux (always up to date). According to I can access IPv4 and IPv6 addresses and other people can access my server via IPv4 and IPv6. Still it is in the |
|
@Yneeb and @MartinX3 Thanks, but please read #8686 (comment). |
|
@yuwata btw, it's easier to use A |
|
Deactivated DHCP entirely and define my static IP and gateway in the .network file. |
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Aug 20, 2021
This fixes the followings: - The corresponding route or address to the gateway address must be in the same link. - IPv6 link local address is not necessary to be reachable. Fixes an issue reported in systemd#8686 (comment).
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Aug 20, 2021
This fixes the followings: - The corresponding route or address to the gateway address must be in the same link. - IPv6 link local address is not necessary to be reachable. Fixes an issue reported in systemd#8686 (comment).
|
Dear @yuwata So if i loose my ssh, i'm a bit fucked 💩 |
|
@MartinX3 No problem. Thank you for your detailed report! |
|
@yuwata and thank you verry much for your fix :) |
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Aug 20, 2021
This fixes the followings: - The corresponding route or address to the gateway address must be in the same link. - IPv6 link local address is not necessary to be reachable. Fixes an issue reported in systemd#8686 (comment).
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Aug 21, 2021
This fixes the followings: - The corresponding route or address to the gateway address must be in the same link. - IPv6 link local address is not necessary to be reachable. Fixes an issue reported in systemd#8686 (comment).
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Aug 22, 2021
This fixes the followings: - The corresponding route or address to the gateway address must be in the same link. - IPv6 link local address is not necessary to be reachable. Fixes an issue reported in systemd#8686 (comment).
bluca
pushed a commit
to systemd/systemd-stable
that referenced
this issue
Aug 22, 2021
This fixes the followings: - The corresponding route or address to the gateway address must be in the same link. - IPv6 link local address is not necessary to be reachable. Fixes an issue reported in systemd/systemd#8686 (comment). (cherry picked from commit 3333350)
|
Let's close this. If you find that an interface stuck at configuring state, usually its reason is different to others. And already the original reporter stop to respond. Please open a new issue page with debugging logs and your configs. |
|
I'd just like to report that I hit this issue (the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
systemd version the issue has been seen with
237-3ubuntu7
Used distribution
Ubuntu 18.04 (beta 2)
In case of bug report: Expected behaviour you didn't see
Network configured with systemd-networkd is in "routable (configured)" state
In case of bug report: Unexpected behaviour you saw
Network configured with systemd-networkd is in "routable (configuring)" state, stuck.
systemd-networkd-wait-online times out
In case of bug report: Steps to reproduce the problem
/etc/systemd/networkd/wired.network
$ cat wired.network
DNS servers are configured in systemd-resolved.conf
$ networkctl status -a
$ sudo systemctl status systemd-networkd-wait-online.service
What is it waiting for? My ethernet network interface is up and running, why is it stuck at "configuring", what is it missing?
I've tried DHCP configuration instead of a static IP, and it worked (systemd-networkd obtained a different IP over DHCP) but no effect on the bug - interface still stuck at "configuring" and systemd-networkd-wait-online still timing out.
$ networkctl status -a
The text was updated successfully, but these errors were encountered: