Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#63401 - Networkmanager 1.20 loses connection after a while

Attached to Project: Arch Linux
Opened by Henk (henkv) - Wednesday, 07 August 2019, 14:17 GMT
Last edited by freswa (frederik) - Saturday, 22 February 2020, 20:47 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Networkmanager 1.20 loses the wireless connection after a while. The adapter is still associated with the ap, but it has no connection to the gateway.
A downgrade to version 1.18 solves the issue.

Additional info:
Networkmanager 1.20
Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
Linux kernel 5.2.6-arch1-1-ARCH

Steps to reproduce:
This task depends upon

Closed by  freswa (frederik)
Saturday, 22 February 2020, 20:47 GMT
Reason for closing:  None
Additional comments about closing:  This seems pretty stalled to me. If it's still an issue, please fill a re-open request. Thank you :)
Comment by François Guerraz (kubrick) - Thursday, 08 August 2019, 09:29 GMT
Yes, another untested botched release of NM...
Comment by Thomas Haller (thom311) - Thursday, 08 August 2019, 13:02 GMT
Can you provide a level=TRACE file showing the issue?

See the comment at https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 for how to get the logfile. Note also the comment about private data and journal's rate-limiting.

Thank you.
Comment by Henk (henkv) - Tuesday, 13 August 2019, 10:04 GMT
Log with level=TRACE enabled attached
Comment by Thomas Haller (thom311) - Wednesday, 14 August 2019, 08:43 GMT
in the log it seems NM connects successfully. Also, all the connectivity checks seem to indicate full connectivity. The last up until at

<debug> [1565688943.3279] connectivity: (wlp2s0,IPv4,330) check completed: FULL; expected response

Afterwards, you see that supplicant was roaming twice to another access point, but from the log that appears to be successful.
Of course, the fact that roaming is even attempted, indicates that the signal was not good to begin with.

Anyway, from the logfile it is not clear that afterwards connectivity was lost, or what NetworkManager did wrong here
(or why 1.18 would behave differently).


Since you say that this doesn't happen with 1.18, it might be interesting to try with a wpa-supplicant with fast BSS transition disabled. That means to compile supplicant with CONFIG_IEEE80211R=n, so that NM no longer says: "supplicant: FT is supported"
(or alternatively, recompile NetworkManager 1.20, and patch it so that it always thinks FT is not supported (https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/supplicant/nm-supplicant-manager.c?id=02e5a8d10a39f0f401b72f3a0a39619770fe51de#n362))
Comment by Henk (henkv) - Thursday, 15 August 2019, 07:50 GMT
I recompiled wpa-supplicant with CONFIG_IEEE80211R=n, but it did not fix the issue.

Loading...