Bug 385406 - plasma-nm fails to fetch WWAN (mobile broadband) secrets from keychain
Summary: plasma-nm fails to fetch WWAN (mobile broadband) secrets from keychain
Alias: None
Product: plasma-nm
Classification: Plasma
Component: general (show other bugs)
Version: 5.10.5
Platform: Debian unstable Linux
: NOR major
Target Milestone: ---
Assignee: Jan Grulich
Depends on:
Reported: 2017-10-05 17:15 UTC by onitake
Modified: 2018-05-28 11:56 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description onitake 2017-10-05 17:15:47 UTC
This bug has started occurring a few months ago, not sure in which plasma-nm version. I'm currently on Debian version 4:5.10.5-2 and it is still present.

When I create an NM entry for a mobile broadband modem and set a per-user PIN code and the PPP password, I expect these secrets to be stored in the KDE keychain.
This seems to be the case, but when making a connection, it looks like the NM daemon fails to fetch them back from the keychain. No error message is displayed, but I get several of password dialogues (PIN, superuser, PPP twice).
After entering all these passwords, the connection succeeds, but this is a very bad user experience.

When I open the NM entry in the connection editor KCM, a popup saying "Failed to get secrets for Connection: No agents were available for this request" is displayed.
Comment 1 Jan Grulich 2017-10-23 10:06:29 UTC

*** This bug has been marked as a duplicate of bug 377473 ***
Comment 2 Jan Grulich 2017-10-24 06:30:20 UTC
This is indeed a different issue and I've been able to reproduce it. From my investigation this looks like an issue in NetworkManager which doesn't ask secret agent to store secrets for gsm connections. If you specify that you want your secrets to be stored unencrypted then it will work.
Comment 3 Jan Grulich 2017-11-02 11:08:42 UTC
NM bug for reference: https://bugzilla.gnome.org/show_bug.cgi?id=789383
Comment 4 onitake 2017-11-02 17:59:57 UTC
Thank you, Jan!