GNOME Bugzilla – Bug 743472
Wi-Fi keeps disconnecting and reconnecting
Last modified: 2020-11-12 14:32:05 UTC
Created attachment 295367 [details] NetworkManager and wpa_supplicant log After upgrading to NetworkManager 1.0.0 it tries to connect to a configured access point, but quickly after reporting the successful authentication, it disconnects and this process seems to loop over and over again. Environment details =================== * Distribution: Arch Linux x86_64 * Kernel version: 3.18.2 * Network device's brand and model: Intel Corporation Wireless 7260 (rev bb) * Network device's hardware IDs: Subsystem: 8086:4070 Flags: bus master, fast devsel, latency 0, IRQ 30 Memory at f7600000 (64-bit, non-prefetchable) [size=8K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number f8-16-54-ff-ff-f8-24-1a Capabilities: [14c] Latency Tolerance Reporting Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1 Len=014 <?> Kernel driver in use: iwlwifi Kernel modules: iwlwifi * The output of the 'dmesg' command: [ 1066.944057] wlp3s0: authenticate with 54:e6:fc:98:70:00 [ 1066.946589] wlp3s0: send auth to 54:e6:fc:98:70:00 (try 1/3) [ 1066.948931] wlp3s0: authenticated [ 1066.952266] wlp3s0: associate with 54:e6:fc:98:70:00 (try 1/3) [ 1066.955971] wlp3s0: RX AssocResp from 54:e6:fc:98:70:00 (capab=0x431 status=0 aid=4) [ 1066.957468] wlp3s0: associated [ 1066.957553] cfg80211: Calling CRDA to update world regulatory domain [ 1069.108946] wlp3s0: deauthenticating from 54:e6:fc:98:70:00 by local choice (Reason: 3=DEAUTH_LEAVING) [ 1069.116569] cfg80211: Calling CRDA for country: HU [ 1072.872756] wlp3s0: authenticate with 54:e6:fc:98:70:00 [ 1072.875397] wlp3s0: send auth to 54:e6:fc:98:70:00 (try 1/3) [ 1072.877719] wlp3s0: authenticated [ 1072.880494] wlp3s0: associate with 54:e6:fc:98:70:00 (try 1/3) [ 1072.884247] wlp3s0: RX AssocResp from 54:e6:fc:98:70:00 (capab=0x431 status=0 aid=4) [ 1072.885662] wlp3s0: associated [ 1074.842261] wlp3s0: deauthenticating from 54:e6:fc:98:70:00 by local choice (Reason: 3=DEAUTH_LEAVING) [ 1074.851706] cfg80211: Calling CRDA to update world regulatory domain [ 1078.608233] wlp3s0: authenticate with 54:e6:fc:98:70:00 [ 1078.611035] wlp3s0: send auth to 54:e6:fc:98:70:00 (try 1/3) [ 1078.613412] wlp3s0: authenticated [ 1078.615334] wlp3s0: associate with 54:e6:fc:98:70:00 (try 1/3) [ 1078.619559] wlp3s0: RX AssocResp from 54:e6:fc:98:70:00 (capab=0x431 status=0 aid=4) [ 1078.623409] wlp3s0: associated [ 1078.623676] cfg80211: Calling CRDA to update world regulatory domain [ 1080.790033] wlp3s0: deauthenticating from 54:e6:fc:98:70:00 by local choice (Reason: 3=DEAUTH_LEAVING) [ 1080.798726] cfg80211: Calling CRDA to update world regulatory domain * NetworkManager logs (see attached log) * wpa_supplicant logs (see attached log)
I can confirm the problem, same wifi card, same log. Do you need more info/output? Please ask in case.
The same on Arch Linux with different hardware: 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) (rev 01) 02:00.0 0280: 168c:002b (rev 01) Subsystem: 105b:e017 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f4a00000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-15-17-ff-ff-24-14-12 Capabilities: [170] Power Budgeting <?> Kernel driver in use: ath9k Kernel modules: ath9k
I have the same problem, both via wifi and via cable, but only one of my networks seems to be affected. The network that is affected uses a Netgear WNDR3700v2 with OpenWRT 14.07 Barrier Breaker ( maybe this helps to reproduce the problem ), also I have root access on my router, if that helps to gather information. More details following this evening (UTC+1), I can't access the logs right now.
(In reply to comment #3) > I have the same problem, both via wifi and via cable, but only one of my > networks seems to be affected. Using various versions of NetworkManager in a network with OpenWRT 14.07 (on tl-wdr3600) works for me without such issues. I can see that wireless can heavily depend on the hardware and drivers. If you're seeing the problem with wired as well, I would rather suspect configuration changes in the area of autoconfiguration of IPv4/IPv6 hosts. You need to check your logs to see whether the issue is related to the one reported in this bug report at all.
Created attachment 295526 [details] Log of reconnection loop ( SSID is FSMaxB ) I myself can't decide from the logs if this is related or not.
(In reply to comment #5) > Created an attachment (id=295526) [details] > Log of reconnection loop ( SSID is FSMaxB ) > > I myself can't decide from the logs if this is related or not. Your logs IMO show an entirely different issue: Jan 27 00:30:27 max-galago-arch NetworkManager[497]: <info> (wlp3s0): device state change: activated -> failed (reason 'dhcp-start-failed') [100 120 15] I personally don't recommend using NetworkManager with dhcpcd at all, see: https://wiki.gentoo.org/wiki/NetworkManager Contact: https://wiki.gentoo.org/wiki/User:Pavlix
> Your logs IMO show an entirely different issue: So I should create a new bug report, right? It's not like using GNOME 3.14 is very convenient with wifi without NetworkManager. Also this worked with 0.9.10.0.
I've replaced dhcpcd with dhclient and now it works fine.
(In reply to comment #7) > > Your logs IMO show an entirely different issue: > > So I should create a new bug report, right? It's not like using GNOME 3.14 is > very convenient with wifi without NetworkManager. Also this worked with > 0.9.10.0. Generally, yes, you should file a new bug report in such situation. But AFAIK none of the developers use dhcpcd and therefore it should be by default considered broken.
probably we should consider dropping the dhcpcd backend, especially now that we've got the internal backend for people who really want to avoid dhclient for whatever reason.
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).