Bug 1781084

Summary: Wi-Fi password prompt is not showing
Product: Red Hat Enterprise Linux 8 Reporter: Filip Pokryvka <fpokryvk>
Component: NetworkManagerAssignee: Thomas Haller <thaller>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 8.2CC: atragler, bgalvani, jadahl, jkoten, lrintel, pasik, rkhan, sukulkar, thaller, tpelka, vbenes
Target Milestone: rcKeywords: Regression
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-1.22.0-1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 16:53:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1739559    
Attachments:
Description Flags
NM trace logs none

Description Filip Pokryvka 2019-12-09 10:13:08 UTC
Description of problem:
When clicking to activate a new secured Wi-Fi connection (WEP), password dialog does not pop-up and so connection is not activated

Version-Release number of selected component (if applicable):
gnome-control-center-3.28.2-11.el8.x86_64

How reproducible:
always

Steps to Reproduce:
click on secured Wi-Fi in Wi-Fi list

Actual results:
There is no password prompt dialog, the connection is created with empty password

Expected results:
Password prompt dialog should pop-up

Comment 1 Carlos Garnacho 2019-12-12 23:05:46 UTC
The g-c-c wifi panel just requests a connection to be activated. More likely culprits are NetworkManager or gnome-shell. I'm moving to the former.

Comment 2 Thomas Haller 2019-12-13 10:02:36 UTC
please attach a full NetworkManager log with level=TRACE.

See https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 for hints about logging.

Comment 3 Filip Pokryvka 2019-12-13 11:59:48 UTC
Created attachment 1644786 [details]
NM trace logs

Additional info: dialog is not shown only in the first session after boot. I was not able to reproduce later (after logout-login).

Comment 4 Thomas Haller 2019-12-13 14:33:09 UTC
(In reply to Filip Pokryvka from comment #3)
> Created attachment 1644786 [details]
> NM trace logs
> 
> Additional info: dialog is not shown only in the first session after boot. I
> was not able to reproduce later (after logout-login).

<fpokryvk> thaller_, I think connection is created somehere around line 5751... its name is "wep"

Comment 5 Thomas Haller 2019-12-13 14:44:17 UTC
<info>  [1576237691.1784] NetworkManager (version 1.22.0-0.2.el8) is starting... (after a restart)
...
<warn>  [1576237729.5787] device (wlan0): no secrets: No agents were available for this request.


and all the time in between there is no message that any secret agent would register.

I'd expect something like:

  <trace> [1576237678.0766] secret-agent[6439da29f5a6b946]: constructed: :1.1022/org.gnome.Shell.NetworkAgent/1000, owner="test" (unix-process[pid=6413, uid=1000, start=215689]), unique-name=":1.793", capabilities=vpn-hints


gnome-shell is supposed to register as a secret-agent, so that it can prompt the user. It seems that is not happening.



You restarted NetworkManager service (why?). Maybe gnome-shell has an issue re-registering the secret-agent when NetworkManager restarts. Does it work when you start gnome-shell after NetworkManager?

Comment 6 Thomas Haller 2019-12-13 15:40:34 UTC
ok, I tested now (on Fedora 31)...

when I restart NetworkManager, then gnome-shell won't re-register as secret agent. That is a bug.

Whether that is the same bug as originally reported, is not clear.


Anyway, reassigning to gnome-shell...

Comment 7 Florian Müllner 2019-12-13 18:10:27 UTC
(In reply to Thomas Haller from comment #6)
> ok, I tested now (on Fedora 31)...
> 
> when I restart NetworkManager, then gnome-shell won't re-register as secret
> agent. That is a bug.

Isn't that what the auto-register property should do?

https://gitlab.gnome.org/GNOME/gnome-shell/blob/master/js/ui/components/networkAgent.js#L653

Comment 8 Thomas Haller 2019-12-15 15:31:04 UTC
> Isn't that what the auto-register property should do?

Right... seems to be a bug in libnm's NMSecretAgentOld then(?!)

investigating...

Comment 9 Thomas Haller 2019-12-15 17:26:42 UTC
seems a libnm issue.

I bisected it to https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ce0e898fb476df740a1c337ac9910f504251c466


(btw, that patch has a few issues, it requires the following patch too, to work at all):

```
diff --git i/libnm/nm-client.c w/libnm/nm-client.c
index 590511cd1331..8b7ffbf10bf2 100644
--- i/libnm/nm-client.c
+++ w/libnm/nm-client.c
@@ -666,6 +666,14 @@ _nm_client_queue_notify_object (NMClient *self,
 	nm_assert (NM_IS_OBJECT (nmobj) || NM_IS_CLIENT (nmobj));
 
 	base = (NMObjectBase *) nmobj;
+
+	if (base->is_disposing) {
+		/* Don't emit property changed signals once the NMClient
+		 * instance is about to shut down. */
+		nm_assert (nmobj == self);
+		return;
+	}
+
 	if (c_list_is_empty (&base->queue_notify_lst)) {
 		c_list_link_tail (&NM_CLIENT_GET_PRIVATE (self)->queue_notify_lst_head,
 		                  &base->queue_notify_lst);
@@ -1610,7 +1618,7 @@ nml_dbus_property_o_clear (NMLDBusPropertyO *pr_o,
 	pr_o->owner_dbobj = NULL;
 	pr_o->meta_iface = NULL;
 	pr_o->dbus_property_idx = 0;
-	pr_o->is_ready = TRUE;
+	pr_o->is_ready = FALSE;
 }
 
 void
```



Only strage that the patch doesn't change `NMSecretAgentOld`...

Comment 10 Thomas Haller 2019-12-16 09:30:02 UTC
it also reproduces with `nmcli agent secret`, and the bug is in NMSecretAgentOld.

It seems to be a race (that was there for a long time, but only hits since reworking other parts of libnm)...

Comment 13 Filip Pokryvka 2019-12-18 08:45:11 UTC
Covered by gnome-control-center test @wifi_pskwep_connect, no more present in NetworkManager-1.22.0-1.el8

Comment 15 errata-xmlrpc 2020-04-28 16:53:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1847