Bug 1087339 - kwallet takes too long to ask for password (NetworkManager?)
kwallet takes too long to ask for password (NetworkManager?)
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: GNOME
Current
x86-64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-28 16:39 UTC by avx avx
Modified: 2019-07-15 10:30 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
`sudo journalctl` (222.46 KB, text/plain)
2018-03-28 16:41 UTC, avx avx
Details

Note You need to log in before you can comment on or make changes to this bug.
Description avx avx 2018-03-28 16:39:30 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build Identifier: 

As first asked/reported in this thread on reddit: https://www.reddit.com/r/openSUSE/comments/87in7z/tw_kwallet_takes_very_long_to_ask_for_password/ it takes my system a long time to ask for the password to unlock kwallet and as such give me network access.

As requested in this thread, I'll upload parts of my journal.

Reproducible: Always

Steps to Reproduce:
1. login to plasma
2. see some network services fail (update servers cant be reached, etc)
3. wait
4. wait some more
5. finally kwallet prompt, unlock, works
Actual Results:  
pita

Expected Results:  
instant popup for the password
Comment 1 avx avx 2018-03-28 16:41:09 UTC
Created attachment 765292 [details]
`sudo journalctl`
Comment 2 Fabian Vogt 2018-03-29 08:13:17 UTC
Seems like a NetworkManager bug to me:

Mär 28 18:11:09 linux-v37s NetworkManager[1442]: <info>  [1522253469.5419] device (wlp4s0): Activation: (wifi) access point 'WLAN-289251' has security, but secrets are required.
Mär 28 18:11:09 linux-v37s NetworkManager[1442]: <info>  [1522253469.5420] device (wlp4s0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Mär 28 18:11:09 linux-v37s NetworkManager[1442]: <info>  [1522253469.5420] sup-iface[0x55c94ffcc820,wlp4s0]: wps: type pbc start...
Mär 28 18:11:09 linux-v37s NetworkManager[1442]: <warn>  [1522253469.5436] device (wlp4s0): No agents were available for this request.
Mär 28 18:11:09 linux-v37s NetworkManager[1442]: <info>  [1522253469.5723] device (wlp4s0): supplicant interface state: ready -> disconnected
Mär 28 18:11:09 linux-v37s NetworkManager[1442]: <info>  [1522253469.5731] device (wlp4s0): supplicant interface state: disconnected -> inactive
Mär 28 18:11:09 linux-v37s NetworkManager[1442]: <info>  [1522253469.5781] device (wlp4s0): supplicant interface state: inactive -> scanning

Then later:

Mär 28 18:11:39 linux-v37s NetworkManager[1442]: <info>  [1522253499.3764] device (wlp4s0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
Mär 28 18:11:39 linux-v37s NetworkManager[1442]: <info>  [1522253499.3770] manager: NetworkManager state is now DISCONNECTED
Mär 28 18:11:39 linux-v37s NetworkManager[1442]: <warn>  [1522253499.3781] device (wlp4s0): Activation: failed for connection 'WLAN-289251'
Mär 28 18:11:39 linux-v37s NetworkManager[1442]: <info>  [1522253499.3797] device (wlp4s0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')

My interpretation is that the scanning of the device causes NM to delay the transition to the failed state,
which is a necessary precondition for a retry.