GNOME Bugzilla – Bug 767317
Reenabling or waking from suspend nm-applet fails
Last modified: 2020-11-12 14:34:33 UTC
There's 10 users having reported this bug on launchpad Bug #1589401 https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1589401 We have been advised to report the bug here ? * * * * * * * * * Reenabling or waking from suspend nm-applet fails to show correct icon in network manager applet in the panel. Instead of showing wiFi beam it shows up/down arrows of ehternet connection. Also list if Wifi AP's are missing. Actual Wifi connecting are not affected and continues to work despite wrong information from nm-applet Killing nm-applet and restarting it solves it. * * * * * To reproduce. 1. Connect to wifi AP, get 'beam' icon in nm-applet 2. Suspund laptop. 3. wake up from suspend, observe that 'wifi beam' icon and Wifi list are missing from nm-applet. 4 execute 'killall nm-applet' and restarting 'nm-applet', will show Wifi connection in the panel again. * * * * * Linux Ubuntu1604-L450 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux network-manager: Installed: 1.2.0-0ubuntu0.16.04.2 Candidate: 1.2.0-0ubuntu0.16.04.2 Version table: *** 1.2.0-0ubuntu0.16.04.2 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-V (rev 03) 04:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)
Created attachment 329244 [details] Screenshot of failed icon.
*** Bug 767316 has been marked as a duplicate of this bug. ***
Any updates on this? I would like to know if connection drops every 5 ~ 15 minutes (more often when I'm AFK for a few seconds), along with the reported issues, are related to this same bug. Network-manager is currently unreliable here even for the simple purpose of web browsing. I must run "sudo systemctl restart network-manager" ALL THE TIME, really.
(In reply to Henry J. Douglas from comment #3) > Any updates on this? I would like to know if connection drops every 5 ~ 15 > minutes (more often when I'm AFK for a few seconds), along with the reported > issues, are related to this same bug. It seems unlikely to me, connection drops are a problem in NM core, this bug is about the applet showing wrong information after a suspend. > Network-manager is currently > unreliable here even for the simple purpose of web browsing. I must run > "sudo systemctl restart network-manager" ALL THE TIME, really. Can you please file a separate bug and attach trace logs? To increase logging level, set 'level=TRACE' in the [logging] section of /etc/NetworkManager/NetworkManager.conf and restart the service. Then attach the output of 'journalctl -u NetworkManager -b'. Please also specify the NM version. Thanks!
There are no loss of WiFi connection, it's only nm-applet (icon) that's failing, as show in the attached picture. Network-manager still has and shows the connection.
Thanks! I'll create a bug report if that issue persists. However, I think I got the applet to show the correct status (and fixed the connection drops). I've upgraded my TP-Link wireless router's firmware today (4 years outdated), configured it again, connected through another ISP and network-manager sucessfully managed the connection after several suspend/reboot (no more ethernet arrows and connection is stable). If someone is able to confirm this (checking/upgrading wireless router), please give it a try. My wireless card is Intel Wireless 3160.
I see the same problem when coming out of suspend: Ubuntu 16.04 Unity, Dell XPS 13 9333 (Sputnik 3), Intel Wireless 7260. Ubuntu 16.04 Unity, Lenovo Thinkpad X220, Intel Wireless 6205. If I restart the network-manager service, it recovers until the next suspend: sudo systemctl restart network-manager.service On boot, the systems do show a list of wireless networks, but with the Ethernet connected icon. They are unable to join any WiFi network due to 'Insufficient privileges' and do not automatically join known networks. Once the user is logged in the applet works, until it is put into, and recovers from, suspend. This does not depend on the AP in use, and was not an error under the previous Ubuntu LTS release.
We are 30 people with this bug on launchpad now.
For some reason, if I use Ubuntu (Unity), the issue is gone (different packages, maybe?). Ubuntu MATE, Xubuntu and others will bump into this. That is why I made comments reporting that it was working, but it was just on Ubuntu. Now I'll just wait.
Created attachment 330279 [details] bluetooth affected by nm bug Bluetooth applet will no longer display the "make visible" option after NetworkManager goes dark (after suspend).
Running "sudo systemctl restart bluetooth" restores it to normal.
(In reply to mote from comment #8) > We are 30 people with this bug on launchpad now. We need some more information to debug this problem: - if you start the applet from a terminal and perform a suspend/resume cycle, do you see any message when nm-applet fails? - since downstream has some patches applied, can you build the applet from the upstream repository [1] or from the distro package but without patches and confirm the problem still happens? Thanks. [1] https://git.gnome.org/browse/network-manager-applet
Running nm-applet from terminal and suspend/wakeup the laptop gives this output ---------- mads@Ubuntu1604-L450:~$ killall nm-applet mads@Ubuntu1604-L450:~$ nm-applet (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed (nm-applet:22940): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed ---------- I'm not skilled enough to do the building of the applet, but i will get the answer from some of the others on launchpad and return it here. It might take some time i'm on vacation.
I'll try to build it now without any patches, and report back :)
Build failed :/ Not sure why, but I tried with all the new patches from https://launchpad.net/ubuntu/+source/network-manager/1.2.0-0ubuntu0.16.04.3 + dependencies (libnm-glib-vpn1, libnm-glib4, libnm-util2, libnm0) cant reproduce anymore.
I can't see a problem with nm-applet icon neither on Arch Linux nor Fedora. As far as I know, Ubuntu uses its own patches that may cause the problem.
There's some development on the bug on launchpad. I'll report back soon.
(In reply to Jiri Klimes from comment #16) > I can't see a problem with nm-applet icon neither on Arch Linux nor Fedora. > As far as I know, Ubuntu uses its own patches that may cause the problem. I have this issue with nm-applet and XFCE on Arch Linux since several weeks, so it's not limited to Ubuntu.
(In reply to b81 from comment #18) > (In reply to Jiri Klimes from comment #16) > > I can't see a problem with nm-applet icon neither on Arch Linux nor Fedora. > > As far as I know, Ubuntu uses its own patches that may cause the problem. > > I have this issue with nm-applet and XFCE on Arch Linux since several weeks, > so it's not limited to Ubuntu. It would be useful to have also NM logs. Would you please set: [logging] level=TRACE in /etc/NetworkManager/NetworkManager.conf, restart the NM service, reproduce the issue and then attach the journal log ('journalctl -u NetworkManager -b')? Thanks!
I will get feedback from launchpad as well on this as well.
I did as Beniamino asked, then did a reboot, did a suspend/resume (arrows appeared), and the logging is 1997 lines long. I will include as an attachment. Please note: to protect my privacy, I changed the IPv6 address range in the logging. Ubuntu 16.10.
Created attachment 339356 [details] Output of "journalctl -u NetworkManager -b", with suspend around 23:41 Output of "journalctl -u NetworkManager -b", with suspend around 23:41
Created attachment 339368 [details] [review] debug-status-icon.patch (In reply to sander.jonkers from comment #22) > Created attachment 339356 [details] > Output of "journalctl -u NetworkManager -b", with suspend around 23:41 > > Output of "journalctl -u NetworkManager -b", with suspend around 23:41 Everything looks fine on NM side. Does anybody have the chance to build the applet with the following patch, run it from the terminal and attach the output after the issue happens? (please also click on the icon afterwards). The patch should apply cleanly on top of the Ubuntu 16.04 version.
Created attachment 341018 [details] [review] Check the prefix 'wlan' for WiFi devices. Hi, This is my proposed fix for this issue. I didn't test it yet because I can not reduplicate this issue now. I am seeking people to confirm if this patch works or not. Nov 28 06:22:36 u-Precision-5520 kernel: ath10k_pci 0000:01:00.0 wlp1s0: renamed from wlan0 Nov 28 06:22:36 u-Precision-5520 NetworkManager[772]: <trace> [1480332156.5568] platform-linux: event-notification: NEWLINK, seq 0: 2: wlan0 <DOWN;broadcast,multicast> mtu 1500 arp 1 ethernet? not-init addrgenmode eui64 addr 40:49:0F:8A:E5:97 Nov 28 06:22:36 u-Precision-5520 NetworkManager[772]: <debug> [1480332156.5568] platform: signal: link added: 2: wlan0 <DOWN;broadcast,multicast> mtu 1500 arp 1 ethernet? not-init addrgenmode eui64 addr 40:49:0F:8A:E5:97 driver unknown Nov 28 06:22:36 u-Precision-5520 NetworkManager[772]: <warn> [1480332156.5569] device (wlan0): failed to find device 2 'wlan0' with udev Nov 28 06:22:36 u-Precision-5520 NetworkManager[772]: <info> [1480332156.5569] device (wlan0): driver '(null)' does not support carrier detection. Nov 28 06:22:36 u-Precision-5520 NetworkManager[772]: <debug> [1480332156.5569] device[0xab4b80] (wlan0): constructed (NMDeviceEthernet) Nov 28 06:22:36 u-Precision-5520 NetworkManager[772]: <debug> [1480332156.5569] device[0xab4b80] (wlan0): start setup of NMDeviceEthernet, kernel ifindex 2 Nov 28 06:22:36 u-Precision-5520 NetworkManager[772]: <debug> [1480332156.5570] platform-linux: error reading /sys/class/net/wlan0/phys_port_id: Failed to open file '/sys/class/net/wlan0/phys_port_id': No such file or directory Nov 28 06:22:36 u-Precision-5520 NetworkManager[772]: <debug> [1480332156.5570] platform-linux: error reading /sys/class/net/wlan0/dev_id: Failed to open file '/sys/class/net/wlan0/dev_id': No such file or directory
I'm not really sure my problem is this, bug 571524 or bug 774268. Also, I'm on arch and not on ubuntu. But since I switched to latest git (was 1.4.2, and for both nm and applet) icon has been rock solidly steady.
(In reply to Shih-Yuan Lee (FourDollars) from comment #24) > Created attachment 341018 [details] [review] [review] > Check the prefix 'wlan' for WiFi devices. > > Hi, > > This is my proposed fix for this issue. I don't think this patch fixes the same issue reported in this bugzilla. Logs in comment 22 indicate that NM correctly detects the wifi interface type and also successfully activate a connection on it, but according to the comments, nm-applet believes an ethernet connection is active. So the fix should be in the applet, while NM is behaving correctly. The race condition fixed by your patch is discussed in bug 775613.
I'm on Arch ('pacman -Syu' on 2016-12-07) and experiencing something similar with NetworkManager 1.4.2 and nm-applet 1.4.2. If the only available wifi network is set to "Store the password only for this user" (i.e. it is stored in Gnome Keyring) nm-applet icon will flash once indicating it is trying to connect but then it will go to its unconnected icon and the list of wifi networks will be empty. The connection is established though, verify with ping or similar. If I change the wifi network to "Store the password for all users" and reboot the problem is gone. The nm-applet icon correctly appears as connecting, then as connected, and the list of wifi networks is populated as it should be. The problem persist with NM and nm-applet version 1.2.2, but it disappears with latest git version (NM 1.5.2, and nm-applet 1.4.3). Definetly also just an nm-applet problem, the since NM is correctly establishing connection. I have no idea which logs to get to back this up, but if anyone is interested and let me know which I'll get them!
I have this issue on Ubuntu MATE. The easiest work around for me is to run the following command whenever this bug presents itself: sudo iwlist <interface> scan So it appears to me that the issue is that a rescan isn't always called when a device resumes from suspend. I'm not knowledgeable on how Network Manager is developed, but I would think if it simply calls the rescan, that would solve it.
When resuming from suspend and hitting this issue, the networkmanager logs show: NetworkManager[773]: <info> [1488932351.8820] manager: wake requested (sleeping: yes enabled: yes) NetworkManager[773]: <info> [1488932351.8821] manager: waking up... NetworkManager[773]: <info> [1488932351.8823] device (wlp58s0): state change: unmanaged -> unavailable (reason 'managed') [10 20 2] NetworkManager[773]: <info> [1488932354.2067] manager: NetworkManager state is now CONNECTED_LOCAL NetworkManager[773]: <info> [1488932354.2946] device (wlp58s0): supplicant interface state: starting -> ready NetworkManager[773]: <info> [1488932354.2948] device (wlp58s0): state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] when the issue doesn't occur, we also see: NetworkManager[773]: <info> [1488955550.0568] device (wlp58s0): supplicant interface state: ready -> inactive NetworkManager[773]: <info> [1488955550.0888] policy: auto-activating connection 'testAP' but these are missing when the issue occurs!
Did you try nm 1.6.2 and nm-applet 1.4.4?
(In reply to Jay from comment #28) > I have this issue on Ubuntu MATE. The easiest work around for me is to run > the following command whenever this bug presents itself: > > sudo iwlist <interface> scan > > So it appears to me that the issue is that a rescan isn't always called when > a device resumes from suspend. I'm not knowledgeable on how Network Manager > is developed, but I would think if it simply calls the rescan, that would > solve it. As reported in previous comments, NM already rescans and activates the Wi-Fi connection after the resume, so the problem seems to be in the applet. If you do a 'nmcli connection' from the terminal you should see that the wireless interface is active and there is connectivity. Can anybody experiencing the issue please try to recompile the applet with the patch in comment 23 and attach the output?
I noticed in comment 25 that nm-applet 1.4.2 was affected, but 1.4.3 was not. I then saw that comment 25 was made on 11/30. I then looked at the commits since 1.4.2 up to 11/30 and came across: https://git.gnome.org/browse/network-manager-applet/commit/?id=c7533cfcd9c761a152a66f608808187df3155521 I will be trying this locally against Ubuntu 16.04 LTS' 1.2.6 package, but perhaps others want to try on their affected versions?
Note that in Ubuntu, 1.2.6-0ubuntu0.16.04.3 backported this git commit. https://launchpadlibrarian.net/320928941/network-manager-applet_1.2.6-0ubuntu0.16.04.2_1.2.6-0ubuntu0.16.04.3.diff.gz
(In reply to Beniamino Galvani from comment #23) > Created attachment 339368 [details] [review] [review] > debug-status-icon.patch > > (In reply to sander.jonkers from comment #22) > > Created attachment 339356 [details] > > Output of "journalctl -u NetworkManager -b", with suspend around 23:41 > > > > Output of "journalctl -u NetworkManager -b", with suspend around 23:41 > > Everything looks fine on NM side. Does anybody have the chance to build the > applet with the following patch, run it from the terminal and attach the > output after the issue happens? (please also click on the icon afterwards). > The patch should apply cleanly on top of the Ubuntu 16.04 version. @Beniamino Galvani, I have built Network-manager-applet from the Ubuntu Archives version 1.2.6-0ubuntu0.16.04.3 with your debug output patch from Comment 23 debug-status-icon.patch. I'm still seeing the issue here. I can be pretty proactive in testing changes for this. Let me know if you find anything or need additional debugging. @James Strandboge, This is most definitely not fixed by the wifi switch changes in Ubuntu.
@Beniamino, unfortunately it doesn't look like I'm allowed to upload files to bugzilla.gnome.org, so here's a pastebin. Can you give me upload permissions? http://paste.ubuntu.com/25163049/
(In reply to Dave Chiluk from comment #35) > @Beniamino, unfortunately it doesn't look like I'm allowed to upload files > to bugzilla.gnome.org, so here's a pastebin. Can you give me upload > permissions? Strange, everybody should be able to add an attachment... Which error message do you see? (In reply to Dave Chiluk from comment #34) > I have built Network-manager-applet from the Ubuntu Archives version > 1.2.6-0ubuntu0.16.04.3 with your debug output patch from Comment 23 > debug-status-icon.patch. I'm still seeing the issue here. I can be pretty > proactive in testing changes for this. Let me know if you find anything or > need additional debugging. The log shows that the device is stuck in state 90 (secondaries), which means that it's waiting for another (VPN) connection to start. Do you actually have a secondary set for the the WiFi connection? What is the output of 'nmcli connection show <wifi-connection-name>'? And also, the output of 'nmcli device show wlp2s0' after the wake?
Created attachment 356361 [details] Debug output from patch in #23
Created attachment 356362 [details] nmcli connection show, and nm d show I've attached the requested output.
Created attachment 356363 [details] Screenshot of status of applet Here's a screenshot showing the status of the applet when it gets into this weird state. Please forgive the transparency, as hitting prntscrn makes the menu start to disappear.
I have forgotten how annoying it can be / was / is to use those non-rolling-release distributions. Network Manager (library and applet) is in version 1.8 now, version 1.9 tags existing in the repos. The problem existed for me in version 1.4.2 in December 2016, but it has been gone for quite some time, and it is definitely gone in version 1.8.2.
Thanks @Jonas, but I'm trying to find the exact commit or group of commits that fixes this so that I can push this change back into Ubuntu.
@Dave, yes I know, a noble undertaking! I didn't mean to degrade your effort, I literally had just forgotten how it was like to be stuck with the one version of something which contain a bug. Also it might be useful for others, coming here as a result of searching, to know that the bug is not there in newer versions.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).