Bug 1087339

Summary: kwallet takes too long to ask for password (NetworkManager?)
Product: [openSUSE] openSUSE Tumbleweed Reporter: avx avx <avx.mobile.phone>
Component: GNOMEAssignee: E-mail List <gnome-bugs>
Status: NEW --- QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: fkrueger, fvogt, Willy.Weisz
Version: Current   
Target Milestone: ---   
Hardware: x86-64   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: `sudo journalctl`

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.