Bug 1628263 - wifi doesnt connect from the drop down in live WS F29 Beta 1.1
Summary: wifi doesnt connect from the drop down in live WS F29 Beta 1.1
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException AcceptedBlocker
Depends On:
Blocks: F29BetaFreezeException F29FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2018-09-12 15:18 UTC by sumantro
Modified: 2018-10-08 17:58 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-08 17:58:24 UTC


Attachments (Terms of Use)
NetworkManager log (137.38 KB, text/plain)
2018-09-13 15:13 UTC, Lukas Brabec
no flags Details
journalctl -b (390.94 KB, text/plain)
2018-09-13 15:13 UTC, Lukas Brabec
no flags Details

Description sumantro 2018-09-12 15:18:15 UTC
Description of problem:


wifi doesnt connect after booting into WS live. Although does work when one goes into  airoplane mode and tries to reactivate from the setting menu after a re-scan


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Boot in Fedora 29 WS Live Beta 1.1
2. Drop down the list from the top right corner. select the wifi ssid you want to connect
3. keep hitting connect, as it wont connect 

Actual results:

Doesnt connect

Journalctl reveals

Sep 12 15:00:30 localhost org.gnome.Shell.desktop[1610]: Window manager warning: last_user_time (122096) is greater than comparison timestamp (122051).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
Sep 12 15:00:30 localhost org.gnome.Shell.desktop[1610]: Window manager warning: W2 (liveuser@l) appears to be one of the offending windows with a timestamp of 122096.  Working around...

Expected results:

should connect

Additional info:


HW is x220
Kernel 4.18.5-300

Comment 1 Adam Williamson 2018-09-12 21:41:25 UTC
I can reproduce this on my XPS 13 (Skylake). Don't think those journal messages have anything to do with it, though.

When you click "Connect", the button animates briefly, and...that's all that happens. The network list doesn't go away. It doesn't prompt you for a password. It just keeps displaying the network list. As Sumantro says, you can click Connect as many times as you like, but nothin ain't connecting to nothin.

Comment 2 Adam Williamson 2018-09-12 21:45:56 UTC
You can connect fine from the 'Wifi' panel in the Settings app, note.

Proposing this as an FE issue; it won't affect wired networking, and there are a couple of workarounds we've already discovered, but it looks bad...

Comment 3 Kamil Páral 2018-09-13 05:47:00 UTC
Proposing as a final blocker:
"All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. "
https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria#Default_panel_functionality

Comment 4 Thomas Haller 2018-09-13 06:59:53 UTC
Can somebody provide a complete log of NetworkManager showing the issue, with level=TRACE?

See hints at https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf

Comment 5 Lukas Brabec 2018-09-13 15:13:09 UTC
Created attachment 1483079 [details]
NetworkManager log

Comment 6 Lukas Brabec 2018-09-13 15:13:55 UTC
Created attachment 1483081 [details]
journalctl -b

Comment 7 Parag Nemade 2018-09-17 02:47:56 UTC
I am too facing issues as described here. I am using T460s laptop and following components
kernel-4.18.5-300.fc29.x86_64
NetworkManager-wifi-1.12.2-2.fc29.x86_64

actually I thought in my home there started some range issue from wifi router to the room in which I use wifi on laptop. After looking into f29 beta list bugs, I found this bug and would like to give confirmation that auto-connect does not happen quickly. I too then used to disable the wifi, enable it, let it try to auto-connect the desired router but it keeps failing in first few attempts.

Comment 8 Geoffrey Marr 2018-09-17 20:07:37 UTC
Discussed during the 2018-09-17 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedFreezeException" was made as this is a prominent bug in the Workstation live, and it's the natural way for people to try and use wifi, so fixing it would be desirable.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-17/f29-blocker-review.2018-09-17-16.02.txt

Comment 9 Geoffrey Marr 2018-09-17 20:18:49 UTC
Discussed during the 2018-09-17 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

"All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-17/f29-blocker-review.2018-09-17-16.02.txt

Comment 10 Beniamino Galvani 2018-09-18 14:20:57 UTC
(In reply to Lukas Brabec from comment #5)
> Created attachment 1483079 [details]
> NetworkManager log

I don't see any connection attempt by NM, which makes me think this is a UI bug.

(In reply to Adam Williamson from comment #1)
> I can reproduce this on my XPS 13 (Skylake). Don't think those journal
> messages have anything to do with it, though.
> 
> When you click "Connect", the button animates briefly, and...that's all that
> happens. The network list doesn't go away. It doesn't prompt you for a
> password. It just keeps displaying the network list. As Sumantro says, you
> can click Connect as many times as you like, but nothin ain't connecting to
> nothin.

Can you please run 'journalctl -f' while clicking "Connect" and check if NM gets the activation request, or it's a GUI problem? Which GUI do you use?

Comment 11 sumantro 2018-09-18 14:40:49 UTC
(In reply to Beniamino Galvani from comment #10)
> (In reply to Lukas Brabec from comment #5)
> > Created attachment 1483079 [details]
> > NetworkManager log
> 
> I don't see any connection attempt by NM, which makes me think this is a UI
> bug.
> 
> (In reply to Adam Williamson from comment #1)
> > I can reproduce this on my XPS 13 (Skylake). Don't think those journal
> > messages have anything to do with it, though.
> > 
> > When you click "Connect", the button animates briefly, and...that's all that
> > happens. The network list doesn't go away. It doesn't prompt you for a
> > password. It just keeps displaying the network list. As Sumantro says, you
> > can click Connect as many times as you like, but nothin ain't connecting to
> > nothin.
> 
> Can you please run 'journalctl -f' while clicking "Connect" and check if NM
> gets the activation request, or it's a GUI problem? Which GUI do you use?

Here's the log when I click connect

Sep 18 14:36:03 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:12 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:15 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:16 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:17 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:17 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:18 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:18 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:19 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:20 localhost gnome-shell[1586]: JS ERROR: Error: Expected type utf8 for Argument 'specific_object' but got type 'undefined'
                                             _connect@resource:///org/gnome/shell/ui/status/network.js:942:17
                                             wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Sep 18 14:36:22 localhost gnome-shell[1586]: Object St.Widget (0x564f14f91440), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: == Stack trace for context 0x564f132fe260 ==
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #0   564f1591c920 i   resource:///org/gnome/shell/ui/modalDialog.js:93 (7f47465eddc0 @ 22)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #1   7ffe09ddf800 b   resource:///org/gnome/gjs/modules/_legacy.js:82 (7f47465b0b80 @ 71)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #2   564f1591c868 i   resource:///org/gnome/gjs/modules/_legacy.js:39 (7f47465b08b0 @ 215)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #3   564f1591c7d8 i   resource:///org/gnome/shell/ui/status/network.js:782 (7f4745fdb670 @ 409)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #4   7ffe09de0f30 b   resource:///org/gnome/gjs/modules/_legacy.js:82 (7f47465b0b80 @ 71)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #5   564f1591c750 i   resource:///org/gnome/shell/ui/modalDialog.js:168 (7f47465f53a0 @ 92)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #6   564f1591c6a8 i   resource:///org/gnome/gjs/modules/_legacy.js:82 (7f47465b0b80 @ 71)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #7   564f1591c5e8 i   self-hosted:975 (7f47465edaf0 @ 392)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #8   564f1591c560 i   resource:///org/gnome/shell/ui/tweener.js:91 (7f47465ccf70 @ 37)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #9   564f1591c4c0 i   resource:///org/gnome/gjs/modules/tweener/tweener.js:208 (7f47465dd790 @ 54)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #10   564f1591c3a0 i   resource:///org/gnome/gjs/modules/tweener/tweener.js:342 (7f47465dd820 @ 1742)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #11   564f1591c310 i   resource:///org/gnome/gjs/modules/tweener/tweener.js:355 (7f47465dd8b0 @ 100)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #12   564f1591c298 i   resource:///org/gnome/gjs/modules/tweener/tweener.js:370 (7f47465dd940 @ 10)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #13   564f1591c1c8 i   resource:///org/gnome/gjs/modules/signals.js:128 (7f47465c18b0 @ 386)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #14   564f1591c138 i   resource:///org/gnome/shell/ui/tweener.js:207 (7f47465d9790 @ 159)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #15   564f1591c090 i   resource:///org/gnome/gjs/modules/_legacy.js:82 (7f47465b0b80 @ 71)
Sep 18 14:36:22 localhost org.gnome.Shell.desktop[1586]: #16   564f1591c010 i   resource:///org/gnome/shell/ui/tweener.js:182 (7f47465d9700 @ 15)
Sep 18 14:36:22 localhost gnome-shell[1586]: clutter_actor_destroy: assertion 'CLUTTER_IS_ACTOR (self)' failed

Comment 12 Adam Williamson 2018-09-18 16:00:24 UTC
Aha. That sure looks like a Shell bug, yes.

Comment 13 Adam Williamson 2018-09-18 17:08:35 UTC
This seems to be complaining about this line in js/ui/status/network.js:

this._client.add_and_activate_connection_async(connection, this._device, accessPoints[0].path, null, null)

the arg that's a problem is the third one, "accessPoints[0].path" - that var is called 'specific_object' in the function signature. It seems that's turning out to be undefined for some reason.

I'm not quite 100% sure what sort of an object accessPoints[0] is, but if it's an NM.AccessPoint, then per https://valadoc.org/libnm-glib/NM.AccessPoint.html , those don't seem to have a 'path' property. I'm flailing a bit but not entirely sure how this ever worked...I'll go poke around with some live images and see if I can nail down when it broke.

Comment 14 Adam Williamson 2018-09-18 17:13:12 UTC
Ah, OK, I see - that's the *old* libnm-glib API. This line comes from the port to plain libnm (via g-i), and I think accessPoints[0] is supposed to be a NMAccessPoint:

https://developer.gnome.org/libnm/stable/NMAccessPoint.html

which inherits from NMObject, which *does* have a 'path' property:

https://developer.gnome.org/libnm/stable/NMObject.html#NMObject--path

so, that seems like it ought to be right. Not sure what the problem is.

Comment 15 Adam Williamson 2018-09-18 23:03:59 UTC
Hrmmmmm. In the libnm source, the NMObject path property has a '(skip)' annotation, which I believe means it should be left out of introspected output:

https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations#Symbol_visibility

https://github.com/NetworkManager/NetworkManager/blob/master/libnm/nm-object.c#L1291

Also notable, there is a get_path() method which *does* seem to be intended to be available via introspection:

https://github.com/NetworkManager/NetworkManager/blob/master/libnm/nm-object.c#L101-L116

so I'm inclined to try replacing those '.path' with '.get_path()' ...

That doesn't explain why this suddenly stopped working, as the network.js code has been around since late 2017 and the (skip) annotation in NM dates to 2016, but...I'm gonna try it anyhow.

Comment 17 Fedora Update System 2018-09-18 23:54:37 UTC
gnome-shell-3.30.0-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0f35f06ae0

Comment 18 Fedora Update System 2018-09-18 23:54:48 UTC
gnome-shell-3.30.0-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0f35f06ae0

Comment 19 Fedora Update System 2018-09-19 17:09:08 UTC
gnome-shell-3.30.0-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e8c0ea09e0

Comment 20 Adam Williamson 2018-10-08 17:58:24 UTC
This is definitely fixed by now.


Note You need to log in before you can comment on or make changes to this bug.