GNOME Bugzilla – Bug 723746
restart/connection assumption fails with dhcpcd
Last modified: 2020-11-12 14:30:56 UTC
+++ This bug was initially created as a clone of Bug #723739 +++ Created an attachment (id=268256) log after NM restart After upgrading libnl to 3.2.24 I experienced problems with networkmanager, especially the vpnc plugin.After downgrading libnl to 3.2.23 everything works fine. To verify the problem I upgraded once again and restarted the NetworkManager daemon - the result was that it could not even connect the eth0 with errors in log file t It fails if I restart NM after upgrading libnl. See "log after NM restart" attachment. ... # eix networkmanager [I] net-misc/networkmanager Available versions: 0.9.6.4 0.9.8.8 {avahi bluetooth connection-sharing (+)consolekit dhclient +dhcpcd doc gnutls +introspection modemmanager +nss +ppp resolvconf systemd test vala +wext +wifi wimax KERNEL="linux"} Installed versions: 0.9.8.8(21:08:08 28.01.2014)(avahi bluetooth connection-sharing consolekit dhcpcd introspection modemmanager nss ppp resolvconf wext wifi -dhclient -gnutls -systemd -test -vala KERNEL="linux") Homepage: http://projects.gnome.org/NetworkManager/ Description: Universal network configuration daemon for laptops, desktops, servers and virtualization hosts
This part of the bug is unrelated to libnl; the problem seems to be that if you restart NM while a dhcpcd-based dhcp connection is open, then NM can't re-claim that connection, because it tries to start a new dhcpcd, which fails because one is already running.
I'm not sure if you're right. I've just updated libnl, stoped NM, killed dhcpcd, and started NM. It did connect, updated the ip address, but there was no connectivity with anything. Unfortunately there are no errors in /var/log/messages. I couldn't even ping my eth0 address, only the 127.0.0.1 worked. After downgrading to libnl-3.2.23 everything is fine.
OK, so if you kill dhcpcd, then you get bug 723739, but that's not what's happening in the "log after NM restart" log. NM never gets far enough to see the libnl-related bug: <info> (eth0): device state change: config -> ip-config (reason 'none') [50 70 0] <info> Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds) <info> dhcpcd started with pid 31386 <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete. dhcpcd already running on pid 29958 (/run/dhcpcd-eth0.pid) <info> (eth0): DHCPv4 client pid 31386 exited with status 1 <info> Activation (eth0) Stage 4 of 5 (IPv4 Configure Timeout) scheduled... <info> Activation (eth0) Stage 4 of 5 (IPv4 Configure Timeout) started... <info> (eth0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5] (repeat twice more) <info> Marking connection 'eth0' invalid. <warn> Activation (eth0) failed for connection 'eth0'
I finally got around to playing around with this bug. I'm using a systemd-based distro (Arch Linux), and the default KillMode in NetworkManager.service is "process". This tells systemd not to kill NetworkManager's children. One of the child processes is either dhclient or dhcpcd (DHCP client) depending on the system's configuration (configurable by changing the dhcp option in /etc/NetworkManager/NetworkManager.conf). In both cases, NetworkManager does *not* kill the DHCP client when shutting down. This means that if I set the dhcp option to dhcpcd, I have the original symptom of no network access. However, If I set the service file's KillMode to control-group, the above issue does not occur because the DHCP client is killed when NetworkManager shuts down. So, a new DHCP client is launched cleanly. See https://wiki.archlinux.org/index.php/Talk:NetworkManager for more information (under "Add recommendation to install dhclient")
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).