After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760999 - [PATCH] SecretAgent tends to get very unreliable
[PATCH] SecretAgent tends to get very unreliable
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.18.x
Other Linux
: Normal major
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2016-01-22 17:49 UTC by Lubomir Rintel
Modified: 2016-01-27 12:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A fix (2.79 KB, patch)
2016-01-26 16:49 UTC, Lubomir Rintel
accepted-commit_now Details | Review

Description Lubomir Rintel 2016-01-22 17:49:30 UTC
Not sure how I can debug this as there are no errors in the system journal. Nevertheless:

Version: gnome-shell-3.18.3-1.fc23.x86_64

1.) GNOME Shell doesn't respond to a secrets request and NetworkManager just waits for a timeout:

Here's a connection secrets request that went on without a response:

========================================================================
GDBus-debug:Message:
  >>>> SENT D-Bus message (1400 bytes)
  Type:    method-call
  Flags:   none
  Version: 0
  Serial:  8311
  Headers:
    path -> objectpath '/org/freedesktop/NetworkManager/SecretAgent'
    interface -> 'org.freedesktop.NetworkManager.SecretAgent'
    member -> 'GetSecrets'
    destination -> ':1.121'
    signature -> signature 'a{sa{sv}}osasu'
  Body: ({'connection': {'id': <'abcd'>, 'uuid': <'703f2a5c-f3d3-458a-9aa1-585f08816261'>, 'type': <'vpn'>, 'permissions': <@as []>, 'autoconnect': <false>, 'timestamp': <uint64 1446719223>, 'secondaries': <@as []>}, 'ipv6': {'method': <'auto'>, 'dns': <@aay []>, 'dns-search': <@as []>, 'addresses': <@a(ayuay) []>, 'routes': <@a(ayuayu) []>, 'ip6-privacy': <0>, 'addr-gen-mode': <0>, 'address-data': <@aa{sv} []>, 'route-data': <@aa{sv} []>}, 'ipv4': {'method': <'auto'>, 'dns': <@au []>, 'dns-search': <@as []>, 'addresses': <@aau []>, 'routes': <@aau []>, 'never-default': <true>, 'address-data': <@aa{sv} []>, 'route-data': <@aa{sv} []>}, 'vpn': {'service-type': <'org.freedesktop.NetworkManager.libreswan'>, 'data': <{'xauthpassword-flags': '2', 'leftxauthusername': 'lrintel', 'xauthpasswordinputmodes': 'ask', 'right': 'vpn', 'pskinputmodes': 'save', 'leftid': 'standard', 'pskvalue-flags': '0'}>, 'secrets': <@a{ss} {}>}}, objectpath '/org/freedesktop/NetworkManager/Settings/29', 'connection', @as [], uint32 4)
  UNIX File Descriptors:
    (none)

2.) Shell just returns an "internal error":

Here's a VPN secrets request:

========================================================================
GDBus-debug:Message:
  >>>> SENT D-Bus message (1424 bytes)
  Type:    method-call
  Flags:   none
  Version: 0
  Serial:  9322
  Headers:
    path -> objectpath '/org/freedesktop/NetworkManager/SecretAgent'
    interface -> 'org.freedesktop.NetworkManager.SecretAgent'
    member -> 'GetSecrets'
    destination -> ':1.121'
    signature -> signature 'a{sa{sv}}osasu'
  Body: ({'connection': {'id': <'abcd'>, 'uuid': <'703f2a5c-f3d3-458a-9aa1-585f08816261'>, 'type': <'vpn'>, 'permissions': <@as []>, 'autoconnect': <false>, 'timestamp': <uint64 1446719223>, 'secondaries': <@as []>}, 'ipv6': {'method': <'auto'>, 'dns': <@aay []>, 'dns-search': <@as []>, 'addresses': <@a(ayuay) []>, 'routes': <@a(ayuayu) []>, 'ip6-privacy': <0>, 'addr-gen-mode': <0>, 'address-data': <@aa{sv} []>, 'route-data': <@aa{sv} []>}, 'ipv4': {'method': <'auto'>, 'dns': <@au []>, 'dns-search': <@as []>, 'addresses': <@aau []>, 'routes': <@aau []>, 'never-default': <true>, 'address-data': <@aa{sv} []>, 'route-data': <@aa{sv} []>}, 'vpn': {'service-type': <'org.freedesktop.NetworkManager.libreswan'>, 'data': <{'xauthpassword-flags': '2', 'leftxauthusername': 'lrintel', 'xauthpasswordinputmodes': 'ask', 'right': 'vpn', 'pskinputmodes': 'save', 'leftid': 'standard', 'pskvalue-flags': '0'}>, 'secrets': <{'pskvalue': 'mehdssfsdf'}>}}, objectpath '/org/freedesktop/NetworkManager/Settings/29', 'vpn', @as [], uint32 4)
  UNIX File Descriptors:
    (none)
========================================================================
GDBus-debug:Message:
  <<<< RECEIVED D-Bus message (197 bytes)
  Type:    error
  Flags:   no-reply-expected
  Version: 0
  Serial:  197584
  Headers:
    error-name -> 'org.freedesktop.NetworkManager.SecretAgent.InternalError'
    reply-serial -> uint32 9322
    destination -> ':1.1464'
    sender -> ':1.121'
    signature -> signature 's'
  Body: ('An internal error occurred while processing the request.',)
  UNIX File Descriptors:
    (none)
Comment 1 Lubomir Rintel 2016-01-22 17:52:43 UTC
When I run gnome-shell --replace I get this output when asking for connection secrets:

Gjs-Message: JS LOG: Invalid connection type: vpn

(gnome-shell:13133): Gjs-WARNING **: JS ERROR: Error: No property 'text' in property list (or its value was undefined)
NetworkSecretDialog<._init@resource:///org/gnome/shell/ui/components/networkAgent.js:60
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
_Base.prototype._construct@resource:///org/gnome/gjs/modules/lang.js:110
Class.prototype._construct/newClass@resource:///org/gnome/gjs/modules/lang.js:204
NetworkAgent<._handleRequest@resource:///org/gnome/shell/ui/components/networkAgent.js:724
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NetworkAgent<._newRequest@resource:///org/gnome/shell/ui/components/networkAgent.js:715
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
Comment 2 Lubomir Rintel 2016-01-26 16:49:29 UTC
Created attachment 319765 [details] [review]
A fix
Comment 3 Dan Williams 2016-01-26 18:05:20 UTC
It should be 'vpn' all the way through for VPN connections.

Perhaps the one that sends 'connection' is acutally coming form a shell/control-center editing request and it sends the wrong setting_name when calling org.freedesktop.Settings.Connection.GetSecrets()?
Comment 4 Dan Williams 2016-01-26 18:16:01 UTC
It looks like nmcli is where the 'connection' part is coming from, but agents should be able to handle this and just return no secrets when they are asked for secrets for a setting that has none.

So patch LGTM.
Comment 5 Rui Matos 2016-01-26 18:21:50 UTC
Comment on attachment 319765 [details] [review]
A fix

ok, now that I understand better how this is supposed to work, seems good indeed