Systemd Causes Very Slow WiFi Association
In September 2019 I encountered problem with WiFi assotiation. After login it takes up to 1 minute for the WiFi to assotiate.
Applications like Firefox will not start until the assotiation finishes. There’s even no feedback, so one can end up with a few Firefox instances after WiFi assotiation finishes. Automatic updates shows errors after login, because network is stil not available. There hasn’t been such a problem before on Fedora 30.
List of methods tried:
Checking different WiFi card. Neither iwlwifi nor rtl (USB) did help. The result is the same: very slow WiFi network assotiation.
→ Result: The very slow WiFi assotiation is not the result of the type of WiFi chipset used. Neither it matters if its internal or USB type.
Removing KDE Wallets secrets and setting them up again. Removing KDE wallet completely. Using non encrypted password. The result is the same: very slow WiFi network assotiation.
→ Result: The very slow WiFi assotiation is neither the result of KDE Wallet nor the WiFi password being stored encrypted.
Installing the newer KDE Plasma (ver. 16.5 with improved network manager). The result is the same: very slow WiFi network assotiation.
Result: The very slow WiFi assotiation is not the resault of faulty plasma-nm. The version does not matter.
NB: Fedora does not update plasma and it happened on the same plasma iteration (worked in the past now it doesn’t = something else did happened because there wasn’t any plasma updates, so which change caused the problem? What did you update and change??).
- Using different system to connect to the same network with the same as above rtl (USB) card. The resault is differnt: WiFi association is so fast I don’t even notice it. Used system Arch+OpenRC+Conmann.
Result: Its not the problem with WiFi router.
Extremely robust and fast assotiation with ARCH+OpenRC+Conmann Zero lags: after login the system is ready and already assotiated to the WiFi. The problem in Fedora is not the WiFi router.
PRIMARY SUSPECT: systemd
Systemd is ether blocking the WiFi assotiation or is incompatible with other desktop environments (including plasma) and is primarily coded for GNOME 3 and only compatible with GNOME 3.
EXPECTED RESULT: immediate fix.
Unless you have other idea, because I have been on Fedora exclusivly since ver. 18 and have never ever asked for help. I stuck with all Fedora issues: beign it either font rendering, AMD drivers or early systemd issues. Now I am determined to have it either immediately fixed or quit Fedora once and for all and start using ARCH. This is a showstopper and I am sad to the extreme.
I’m going to be entirely honest here, you’re throwing around quite a few accusations and demands:
- As much as I’d like to say we have a magic button that can show us exactly what’s going on in your system…we don’t. I’d love to help as much as I can, but immediately coming into a new forum and saying you expect an immediate fix probably isn’t going to make you any friends.
- I highly doubt this is related to systemd, because it only gets bugfix releases during a version cycle. It’s had to compare to your Arch, because you changed a lot of stuff there, on top of Arch itself being a very different distro. Also, systemd isn’t at all tied to GNOME and works just fine with any WM/DE you want, or even on headless systems.
Now onto the problem: could you roughly pinpoint a slightly closer timeframe for when it started? Running
dnf history list will show you all your recent transactions, so assuming this was caused by some update, this command can help narrow down the dates. Once you have a transaction that looks suspect, you can run
dnf history info TRANSACTION_ID in order to see what was changed.
In particular, kernel updates might be of interesting: Arch’s version is a bit newer than Fedora’s, especially if you haven’t updated Fedora in a bit but have a fresh Arch install. Also, you could try booting into an older kernel from your boot menu.
Another thing to try could be a Fedora KDE Spin live CD, to see if that works.
Last thing: it might be helpful to note:
- What’s your WiFi card model?
- Around when did you install Arch?
Can you please ask someone else to step in and help me? Someone who knows what iwlwifi and rtl is?
lspci -k -n -n | grep -i -A 3 -e net
What does this say?
You think I haven’t tried booting with the 2 previous kernels?
After disecting dnf history I can only see my attempts to see if the new plasma will help. It did not.
This is what I found related to networks:
Sat 24 Aug 2019:
Upgrade dnsmasq-2.80-9.fc30.x86_64 @updates
Upgraded dnsmasq-2.80-7.fc30.x86_64 @@System
Upgrade ethtool-2:5.2-1.fc30.x86_64 @updates
Upgraded ethtool-2:5.0-1.fc30.x86_64 @@System
Upgrade geolite2-city-20190806-1.fc30.noarch @updates
Upgraded geolite2-city-20190618-1.fc30.noarch @@System
Upgrade geolite2-country-20190806-1.fc30.noarch @updates
Upgraded geolite2-country-20190618-1.fc30.noarch @@System
Upgrade lm_sensors-libs-3.5.0-6.fc30.x86_64 @updates
Upgraded lm_sensors-libs-3.5.0-3.fc30.x86_64 @@System
some iwl firmware updates too BUT:
disecting iwl firmware updates will not help as the same issue is persistant on another wifi card (see above rtl) so its not the hardware or its ucode. Both cards have the same issue (see above). something else happened.
Wed 21 Aug 2019:
Upgrade NetworkManager-openconnect-1.2.6-1.fc30.x86_64 @updates
Upgraded NetworkManager-openconnect-1.2.4-11.fc30.x86_64 @@System
Fri 16 Aug 2019:
Upgrade dhcp-client-12:4.3.6-36.fc30.x86_64 @updates
Upgraded dhcp-client-12:4.3.6-35.fc30.x86_64 @@System
Upgrade dhcp-common-12:4.3.6-36.fc30.noarch @updates
Upgraded dhcp-common-12:4.3.6-35.fc30.noarch @@System
Upgrade dhcp-libs-12:4.3.6-36.fc30.x86_64 @updates
Upgraded dhcp-libs-12:4.3.6-35.fc30.x86_64 @@System
Wed 14 Aug 2019:
Upgrade NetworkManager-1:1.16.4-1.fc30.x86_64 @updates
Upgraded NetworkManager-1:1.16.2-1.fc30.x86_64 @@System
Upgrade NetworkManager-adsl-1:1.16.4-1.fc30.x86_64 @updates
Upgraded NetworkManager-adsl-1:1.16.2-1.fc30.x86_64 @@System
Upgrade NetworkManager-bluetooth-1:1.16.4-1.fc30.x86_64 @updates
Upgraded NetworkManager-bluetooth-1:1.16.2-1.fc30.x86_64 @@System
Upgrade NetworkManager-config-connectivity-fedora-1:1.16.4-1.fc30.noarch @updates
Upgraded NetworkManager-config-connectivity-fedora-1:1.16.2-1.fc30.noarch @@System
Upgrade NetworkManager-libnm-1:1.16.4-1.fc30.x86_64 @updates
Upgraded NetworkManager-libnm-1:1.16.2-1.fc30.x86_64 @@System
Upgrade NetworkManager-ppp-1:1.16.4-1.fc30.x86_64 @updates
Upgraded NetworkManager-ppp-1:1.16.2-1.fc30.x86_64 @@System
Upgrade NetworkManager-team-1:1.16.4-1.fc30.x86_64 @updates
Upgraded NetworkManager-team-1:1.16.2-1.fc30.x86_64 @@System
Upgrade NetworkManager-wifi-1:1.16.4-1.fc30.x86_64 @updates
Upgraded NetworkManager-wifi-1:1.16.2-1.fc30.x86_64 @@System
Upgrade NetworkManager-wwan-1:1.16.4-1.fc30.x86_64 @updates
Upgraded NetworkManager-wwan-1:1.16.2-1.fc30.x86_64 @@System
I also looked at all commits on cgit fro plasma-nm and didn’t find anything related last chagne for something relevant was in March 2018. But the issue is from August/Sept 2019 so this link below is useless:
I have to agree that it’s neither polite nor kosher to come to any forum and start making demands. There are more gentler ways to pursue this.
Now, I’ve experienced this too, but with KDE, not Gnome. However, for me, it was co-incident with switching out my old harddrive and re-installing F29 (and later, F30) KDE spin on an SSD. Booting to the desktop was every bit as fast as I was led to believe, but yes, it took - maybe - 30 seconds for the connection to wifi to be established. (BTW, it’s always established properly).
I assumed that, although booting is now much faster, it’s taking just as long as ever to establish the wifi connection. I just hadn’t noticed before because previously, the same time was being used up by concurrent booting processes.
Is it possible that this (or other hardware changes) are at the root of JohnKDE’s problem? Just a suggestion.
Thank you josephb for replying. Its the same issue. The same as yours. Did you fix it? HOW?!
If not, does this mean that we are the only ones using KDE on Fedora?! (Since it works on GNOME, who cares, right? Its just two people, they have priorities
with GNOME wayland…).<---- sarcasm (…).
Yes its SSD with 4 core controler. Does that mean SSD is too fast for Fedora ?! <--------- sarcasm (…).
Since updates want to update the system and the network will be ready in one minute, I got ugly crashes and popups in systray. No network=crashes and popups about updates in systray. Ugly.
While testing I was rebooting ad loggin in and out. Many times when I logged out just after that painfully looooong association Fedora had frozen. Logging out made Fedora freeze. Arrggh. Had to do hard reset (can’t remember if REISUO/RISUB worked, probably not), I was too angry and frustrated.
The system is not ready when the wifi is associated. That means that after login it takes like 1 minute to assciate. Result sloooow boot times (everyone is counting the time when they press the button until its ready for work, and since eg. Firefox cannot start until the association is done, the boot time is like ages.).
I am currently testing Manjaro (oh, boy it was not a smooth transition), but after login the wifi is associating in an unnoticable blink of an eye. No problem. Pleaese PM me when you resolve issue.
On the other hand:
- Require safe negotiation
- Treat Unsafe negotiations as broken
Fix Fedora and Firefox (vide heartbleed).
You are being entirely way too nice.