plasma-nm: wifi always spends up to 30 seconds to connect to previous active WLAN after desktop has loaded, fails , then reconnects

[star-buck]

During that phase above, all kinds of things can go wrong, which i will comment in new tickets.
(Making plasma-nm work reliably without failing for WIFI would go a long way to solve the resulting issues, but maybe these issues provide insight to some deeper issues.)

[star-buck]

testing on pinebook next

[subdiff]

As a data point: I experience the same issue on my x86 laptop, but only in Wayland session.

EDIT: this was wrong info. The reason it directly worked was that I started the X session from a second VT and the Wifi connection had been already established in the first session.

[star-buck]

still an issue, not only old laptop, desktop and opentv rpi4, but now thinkpad :/
This is how it goes, already 5 seconds into the login recorded with screenrecord:
http://my.opendesktop.org/index.php/s/4e6yXMnPi7WxTPw

[star-buck]

this affects any services that are started like mycroft or sambamounter, which need a connection to work (e.g. sambamounter doesnt reconnect any samba shares correctly, making it worthless on current debian with wifi).
#182

Is there any method we can apply that makes sure the wifi does get connected right after login like on other DEs i have tested, so it already is well connected before all other stuff is loaded afterwards?

[star-buck]

so installing wicd and removing plasma-nm has this INSTANTLY WORKING :/
I cant even open the screenrecorder fast enough beofre it reconnected, so everything related like samba mounter etc. now works again great...

[star-buck]

after login it already is connected like this:

[davidedmundson]

Switching to wicd seems like an overkill.

NetworkManager has two modes of operation
Either it can store passwords itself, or it can store the wifi passwords in the user's wallet/keychain

The former is a much simpler mode way of working it allows network manager to start connecting to a network a lot earlier in the boot process - with enough config even doable at the SDDM stage, whereas doing it for the user requires login to be basically complete. From what I can tell this is closer to how wicd operates, which I can't see having any useragent to get passwords.

Looking at plasma-nm code, this is decided in the applet by:

            if (KWallet::Wallet::isEnabled()) {
                wifiSecurity->setPskFlags(NetworkManager::Setting::AgentOwned);
            }

The default being "0x0 (none) - the system is responsible for providing and storing this secret."

If you want a quick hotfix, patching that would be easier than a wicd switch.

I'm currently getting some logs of my session plasma-nm wifi connection to see if I can debug the issue going in the initial password fetch from kwallet.

[davidedmundson]

I'm currently getting some logs of my session plasma-nm wifi connection to see if I can debug the issue going in the initial password fetch from kwallet.

Finds from my logs of when the password is stored user side, times refer to ms since login:
4039ms org.kde.plasmanetworkmanagement.init
4319ms password fetch starting
4321ms password fetch complete
21409ms Network activated

That's connecting 21 seconds in, is probably comparable with the "up to 30seconds" that Clemens sees.

Nothing looked inherently broken, the password retrieval fired once and shows it worked first time, but there's scope to improve that initial 4s before it even starts doing plasma password stuff.

[davidedmundson]

A patch that improves the initial wifi connection time, tackling things at hopefully the root of the problem

https://phabricator.kde.org/D26462

[star-buck]

Thanks for the insights! @Scarlett/Leszek: Can we try/ship the hotfix in next ISO?

[star-buck]

Why does it repeatedly fail with an error though first (and on various machines), before truly connecting?

…

On Jan 6, 2020 13:22, "davidedmundson" ***@***.***> wrote: A patch that improves the initial wifi connection time: https://phabricator.kde.org/D26462 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#181?email_source=notifications&email_token=AAGNDBWUTPIT4DG3SXAKHJTQ4MO6PA5CNFSM4HCRQFBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFJNTY#issuecomment-571119311>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGNDBWBKWDML6K3B3CAR53Q4MO6PANCNFSM4HCRQFBA> .

[llelectronics]

Shipping needs us to build plasma-nm which we currently don't do and agreed to not do in the future.
Lets work on a solution and test it locally and then ship it upstream and ping Debian to include the patch.
For now it looks so basic that Debian might agree including it.

[davidedmundson]

Why does it repeatedly fail with an error though first (and on various

That's a good question. I see those errors if I don't have kwallet unlocked automatically on login, but on a working setup I couldn't reproduce. They will make a difference.

---

To make sure I've explained the above properly, you can do a fix quick and dirty fix by disabling kwallet which can be done in a config and is something I know on releases previously.

My patch above will help the kwallet case be marginally faster, but we're talking a difference of just a few seconds. I've just had that accepted by the plasma-nm maintainer (Jan Grulich) and it's merged into master.

[star-buck]

Im talking about the quick fix. But even for that case, we would certainly have to ship it, if debian wouldnt and it was needed to be patched.

…

On Mon, Jan 6, 2020, 15:39 Leszek Lesner ***@***.***> wrote: Shipping needs us to build plasma-nm which we currently don't do and agreed to not do in the future. Lets work on a solution and test it locally and then ship it upstream and ping Debian to include the patch. For now it looks so basic that Debian might agree including it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#181?email_source=notifications&email_token=AAGNDBUHWTM4OH4RGV22KHTQ4M7ARA5CNFSM4HCRQFBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFTX6Y#issuecomment-571161595>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGNDBSL3ZGYJSC26XS3FIDQ4M7ARANCNFSM4HCRQFBA> .