GNOME Bugzilla – Bug 743599
Network interface keeps getting disabled and reenabled
Last modified: 2020-11-12 14:29:37 UTC
Created attachment 295581 [details] Log files of it happening When connecting to my home network it keeps connecting and disconnecting in a loop. This happens on 3 different computers using Archlinux x86_64 with NetworkManager version 1.0.0, both via wifi and via cable. The problem only occurs with one of my routers, a Netgear WNDR3700v2 with OpenWRT 14.07 Barrier Breaker. Not with a TP-Link WR740N v4.6 with OpenWRT 14.07 Barrier Breaker, also not with my Fritz!Box 7320 and the Network of my University using WPA-Enterprise. Comments in this bug report: https://bugzilla.gnome.org/show_bug.cgi?id=743472 suggest that my problem may be related to the use of dhcpcd, but I haven't investigated that any further. The problem first occured after upgrading from 0.9.10.0 to 1.0.0 and downgrading provides a temporary fix. When the problem first occured I was using network-manager-applet 1.0.0 with GNOME 3.14, but I can reproduce this problem even without nm-applet. In the Attachments you can find the NetworkManager logs of it happening. And I did simultaneously capture all the packages on the interface with wireshark (so the logs and the capture should be in sync).
Created attachment 295582 [details] Package capture with wireshark.
Created attachment 295583 [details] The NetworkManager.conf used by Archlinux
Yes, it's because of dhcpcd (or rather, NM's use of dhcpcd), and switching to dhclient will fix things (though we need to do something about the bug with dhcpcd anyway).
I didn't know that dhcpcd is just a fallback. So simply installing dhclient "fixes" the problem ( this seems to be obvious to you, but it wasn't for me ).
(It was only obvious to me because, as you mentioned, the problem was already debugged in bug 743472.) dhcpcd isn't supposed to be "just a fallback", but none of the developers use it, so it tends to not get tested well, and random bugs like this creep in. The main argument for using dhcpcd rather than dhclient is that it's much smaller, but the new internal dhcp client in NM 1.0 should be even smaller, so once that's fully functional, we should probably kill the dhcpcd backend.
(In reply to comment #5) > so once that's fully functional, we should probably kill the dhcpcd backend. That would be great.
Max, also, make sure that there is no "master" dhcpcd process, since that prevents the NM-spawned dhcpcd from returning DHCP information back to NM. NM spawns dhcpcd by independently, so if there is a system dhcpcd service enabled, try disabling that service.
Another approach to this is to get upstream dhcpcd to add a "--no-master" argument that NM would use, which prevents the pass-off-to-master behavior. There is currently no option to do that, if a master process is runnign then dhcpcd will *always* hand the request off.
This looks the same as our problem [1] which caused due to some mishandling in IPv6 configuration via dhcpcd backend. If it's that, another workaround is to set IPv6 to non-DHCP option (e.g. link-local only). [1]:https://bugs.gentoo.org/show_bug.cgi?id=563938
(In reply to Michał Górny from comment #9) > This looks the same as our problem [1] which caused due to some mishandling > in IPv6 configuration via dhcpcd backend. If it's that, another workaround > is to set IPv6 to non-DHCP option (e.g. link-local only). > > [1]:https://bugs.gentoo.org/show_bug.cgi?id=563938 I believe the latest dhcpcd(6.11.3) has fixed the IPV6 master problem but the site is down ATM so I cannot get at the relese notes
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).