Ubuntu
network-manager package

Network manager applet unable to control wifi after suspend in 16.04

Bug #1576747 reported by Dave Chiluk
220
This bug affects 45 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Confirmed
High
Unassigned

Bug Description

After resume from suspend network manager no longer allows me to control my wifi card, view available wireless networks, or select new ones. Oddly enough, I'm still able to communicate on the network that I was connected to prior to suspend.

Running
# sudo service network-manager restart
resolves the issue until the next suspend/resume.

I'll copy what I think is the relevant portion of syslog below
__________________________________________________________________
Apr 29 09:04:20 x1 NetworkManager[849]: <info> [1461938660.4971] manager: wake requested (sleeping: yes enabled: yes)
Apr 29 09:04:20 x1 NetworkManager[849]: <info> [1461938660.4971] manager: waking up...
Apr 29 09:04:20 x1 NetworkManager[849]: <info> [1461938660.4972] device (enp0s31f6): state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]
Apr 29 09:04:20 x1 laptop-mode: Laptop mode
Apr 29 09:04:20 x1 laptop_mode[19059]: Laptop mode
Apr 29 09:04:20 x1 laptop-mode: enabled, not active [unchanged]
Apr 29 09:04:20 x1 laptop_mode[19059]: enabled, not active [unchanged]
Apr 29 09:04:20 x1 systemd[1]: Started Run anacron jobs.
Apr 29 09:04:20 x1 systemd[1]: Reloading Laptop Mode Tools.
Apr 29 09:04:20 x1 anacron[19143]: Anacron 2.3 started on 2016-04-29
Apr 29 09:04:20 x1 anacron[19143]: Will run job `cron.daily' in 5 min.
Apr 29 09:04:20 x1 anacron[19143]: Jobs will be executed sequentially
Apr 29 09:04:20 x1 laptop-mode: Laptop mode
Apr 29 09:04:20 x1 laptop_mode[19145]: Laptop mode
Apr 29 09:04:20 x1 laptop-mode: enabled, not active [unchanged]
Apr 29 09:04:20 x1 laptop_mode[19145]: enabled, not active [unchanged]
Apr 29 09:04:20 x1 systemd[1]: Reloaded Laptop Mode Tools.
Apr 29 09:04:20 x1 kernel: [180451.937599] e1000e: enp0s31f6 NIC Link is Down
Apr 29 09:04:20 x1 NetworkManager[849]: <info> [1461938660.5997] device (wlp4s0): state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Apr 29 09:04:20 x1 kernel: [180451.940588] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
Apr 29 09:04:20 x1 kernel: [180451.941150] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
Apr 29 09:04:20 x1 kernel: [180451.942063] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
Apr 29 09:04:20 x1 kernel: [180451.943308] iwlwifi 0000:04:00.0: can't access the RSA semaphore it is write protected
Apr 29 09:04:20 x1 kernel: [180452.080430] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
Apr 29 09:04:20 x1 kernel: [180452.080804] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
Apr 29 09:04:20 x1 kernel: [180452.081573] iwlwifi 0000:04:00.0: can't access the RSA semaphore it is write protected
Apr 29 09:04:20 x1 NetworkManager[849]: <info> [1461938660.8179] device (enp0s31f6): state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Apr 29 09:04:20 x1 kernel: [180452.157407] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
Apr 29 09:04:20 x1 kernel: [180452.158711] IPv6: ADDRCONF(NETDEV_UP): enp0s31f6: link is not ready
Apr 29 09:04:21 x1 kernel: [180452.364579] IPv6: ADDRCONF(NETDEV_UP): enp0s31f6: link is not ready
Apr 29 09:04:21 x1 NetworkManager[849]: <info> [1461938661.0266] manager: NetworkManager state is now CONNECTED_LOCAL
Apr 29 09:04:21 x1 wpa_supplicant[1102]: dbus: wpa_dbus_get_object_properties: failed to get object properties: (none) none
Apr 29 09:04:21 x1 wpa_supplicant[1102]: dbus: Failed to construct signal
Apr 29 09:04:21 x1 wpa_supplicant[1102]: Could not read interface p2p-dev-wlp4s0 flags: No such device
Apr 29 09:04:21 x1 NetworkManager[849]: <info> [1461938661.1095] device (wlp4s0): supplicant interface state: starting -> ready
Apr 29 09:04:21 x1 NetworkManager[849]: <info> [1461938661.1095] device (wlp4s0): state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42]
Apr 29 09:04:21 x1 kernel: [180452.450294] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
Apr 29 09:04:21 x1 kernel: [180452.551779] [drm] RC6 on
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1646] device (wlp4s0): supplicant interface state: ready -> inactive
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1678] policy: auto-activating connection 'chiluks-5g 1'
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1688] device (wlp4s0): Activation: starting connection 'chiluks-5g 1' (8c69564c-5b6f-4ab4-8e6e-ee3157160892)
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1690] device (wlp4s0): state change: disconnected -> prepare (reason 'none') [30 40 0]
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1691] manager: NetworkManager state is now CONNECTING
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1698] device (wlp4s0): state change: prepare -> config (reason 'none') [40 50 0]
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1700] device (wlp4s0): Activation: (wifi) access point 'chiluks-5g 1' has security, but secrets are required.
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1700] device (wlp4s0): state change: config -> need-auth (reason 'none') [50 60 0]
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1741] device (wlp4s0): state change: need-auth -> prepare (reason 'none') [60 40 0]
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1745] device (wlp4s0): state change: prepare -> config (reason 'none') [40 50 0]
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1747] device (wlp4s0): Activation: (wifi) connection 'chiluks-5g 1' has security, and secrets exist. No new secrets needed.
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1747] Config: added 'ssid' value 'chiluks-5g'
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1749] Config: added 'scan_ssid' value '1'
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1749] Config: added 'key_mgmt' value 'WPA-PSK'
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1749] Config: added 'auth_alg' value 'OPEN'
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1749] Config: added 'psk' value '<omitted>'
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.1858] sup-iface[0x2249d60,wlp4s0]: config: set interface ap_scan to 1
Apr 29 09:04:24 x1 gnome-session[2037]: (nm-applet:2197): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed
Apr 29 09:04:24 x1 gnome-session[2037]: message repeated 6 times: [ (nm-applet:2197): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed]
Apr 29 09:04:24 x1 wpa_supplicant[1102]: wlp4s0: SME: Trying to authenticate with 30:85:a9:e6:8d:ac (SSID='chiluks-5g' freq=5825 MHz)
Apr 29 09:04:24 x1 kernel: [180455.536082] wlp4s0: authenticate with 30:85:a9:e6:8d:ac
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2048] device (wlp4s0): supplicant interface state: inactive -> authenticating
Apr 29 09:04:24 x1 kernel: [180455.544486] wlp4s0: send auth to 30:85:a9:e6:8d:ac (try 1/3)
Apr 29 09:04:24 x1 wpa_supplicant[1102]: wlp4s0: Trying to associate with 30:85:a9:e6:8d:ac (SSID='chiluks-5g' freq=5825 MHz)
Apr 29 09:04:24 x1 kernel: [180455.548879] wlp4s0: authenticated
Apr 29 09:04:24 x1 wpa_supplicant[1102]: wlp4s0: Associated with 30:85:a9:e6:8d:ac
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2142] device (wlp4s0): supplicant interface state: authenticating -> associating
Apr 29 09:04:24 x1 kernel: [180455.551875] wlp4s0: associate with 30:85:a9:e6:8d:ac (try 1/3)
Apr 29 09:04:24 x1 kernel: [180455.552890] wlp4s0: RX AssocResp from 30:85:a9:e6:8d:ac (capab=0x11 status=0 aid=2)
Apr 29 09:04:24 x1 kernel: [180455.554081] wlp4s0: associated
Apr 29 09:04:24 x1 kernel: [180455.554109] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2190] device (wlp4s0): supplicant interface state: associating -> associated
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2293] device (wlp4s0): supplicant interface state: associated -> 4-way handshake
Apr 29 09:04:24 x1 wpa_supplicant[1102]: wlp4s0: WPA: Key negotiation completed with 30:85:a9:e6:8d:ac [PTK=CCMP GTK=CCMP]
Apr 29 09:04:24 x1 wpa_supplicant[1102]: wlp4s0: CTRL-EVENT-CONNECTED - Connection to 30:85:a9:e6:8d:ac completed [id=0 id_str=]
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2394] device (wlp4s0): supplicant interface state: 4-way handshake -> completed
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2395] device (wlp4s0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'chiluks-5g'.
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2395] device (wlp4s0): state change: config -> ip-config (reason 'none') [50 70 0]
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2401] dhcp4 (wlp4s0): activation: beginning transaction (timeout in 45 seconds)
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2413] dhcp4 (wlp4s0): dhclient started with pid 19271
Apr 29 09:04:24 x1 dhclient[19271]: DHCPREQUEST of 192.168.1.197 on wlp4s0 to 255.255.255.255 port 67 (xid=0x5677df51)
Apr 29 09:04:24 x1 dhclient[19271]: DHCPACK of 192.168.1.197 from 192.168.1.1
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2784] address 192.168.1.197
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2784] plen 24 (255.255.255.0)
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2784] gateway 192.168.1.1
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2784] server identifier 192.168.1.1
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2785] lease time 86400
Apr 29 09:04:24 x1 avahi-daemon[783]: Joining mDNS multicast group on interface wlp4s0.IPv4 with address 192.168.1.197.
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2785] hostname 'x1'
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2785] nameserver '192.168.1.1'
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2785] dhcp4 (wlp4s0): state changed unknown -> bound
Apr 29 09:04:24 x1 avahi-daemon[783]: New relevant interface wlp4s0.IPv4 for mDNS.
Apr 29 09:04:24 x1 avahi-daemon[783]: Registering new address record for 192.168.1.197 on wlp4s0.IPv4.
Apr 29 09:04:24 x1 dhclient[19271]: bound to 192.168.1.197 -- renewal in 39558 seconds.
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2862] device (wlp4s0): state change: ip-config -> ip-check (reason 'none') [70 80 0]
Apr 29 09:04:24 x1 whoopsie[855]: [09:04:24] Cannot reach: https://daisy.ubuntu.com
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2885] device (wlp4s0): state change: ip-check -> secondaries (reason 'none') [80 90 0]
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2889] device (wlp4s0): state change: secondaries -> activated (reason 'none') [90 100 0]
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2891] manager: NetworkManager state is now CONNECTED_LOCAL
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2949] manager: NetworkManager state is now CONNECTED_GLOBAL
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2950] policy: set 'chiluks-5g 1' (wlp4s0) as default for IPv4 routing and DNS
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.2951] dns-mgr: Writing DNS information to /sbin/resolvconf
Apr 29 09:04:24 x1 dnsmasq[1806]: setting upstream servers from DBus
Apr 29 09:04:24 x1 dnsmasq[1806]: using nameserver 192.168.1.1#53
Apr 29 09:04:24 x1 NetworkManager[849]: <info> [1461938664.3023] device (wlp4s0): Activation: successful, device activated.
Apr 29 09:04:24 x1 nm-dispatcher: req:2 'up' [wlp4s0]: new request (2 scripts)
Apr 29 09:04:24 x1 nm-dispatcher: req:2 'up' [wlp4s0]: start running ordered scripts...
Apr 29 09:04:24 x1 gnome-session[2037]: (nm-applet:2197): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed
Apr 29 09:04:24 x1 gnome-session[2037]: message repeated 6 times: [ (nm-applet:2197): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed]
__________________________________________________________________

I will attempt to look at this more thoroughly as I get time, but for now I'll just open the bug so others can fell some solidarity if this is more widespread.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: network-manager 1.1.93-0ubuntu4
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Apr 29 09:49:05 2016
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2016-04-25 (3 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
IpRoute:
 default via 192.168.1.1 dev wlp4s0 proto static metric 600
 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
 192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.197 metric 600
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'.

See original description
Revision history for this message
Dave Chiluk (chiluk) wrote :
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Martin (linux-support) wrote :

Could be the same like this? https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1516153

Revision history for this message
Dave Chiluk (chiluk) wrote :

It's possible. I'll mark this as a dupe once we know more.

Revision history for this message
Dave Chiluk (chiluk) wrote :

So it looks as though I'm able to reproduce this by
1. Connecting to wifi access point
2. Suspend
3. Move out of range, but in range of another saved access point.
4. Resume.

My computer automatically connected to the new access point, but does not show any information to that effect.

I'm not sure if the new saved access point is required, but either way you will no longer be able to manage wireless networks through the applet.

Alberto Salvia Novella (es20490446e)
Changed in network-manager (Ubuntu):
importance: Undecided → High
Revision history for this message
Dave Chiluk (chiluk) wrote :

Well under further review. Moving wifi zones does not seem to be necessary, but sleeping for some extended time may be.

I can also confirm that killing and restarting nm-applet is another less-hammerlike workaround.

Revision history for this message
Aeaeaeaeaeae (aeaeaeaeaeae) wrote :

is it possible that there is a link to the mysterious "vribr0"?
...it occurs both in the initial bug desription here, and on my laptop too (I did not configure virbr0 anywhere, but its there since the installation of 16.04, when the wifi problem started)

Revision history for this message
Dave Chiluk (chiluk) wrote :

@aeaeaeaeaeae, virbr0 is owned/created by libvirt as the default network for kvm. This issue very likely unrelated.

Revision history for this message
Sebastien Bacher (seb128) wrote :

can you try to xenial-proposed update and see if it improves things for you?

Revision history for this message
Dave Chiluk (chiluk) wrote :

I just tried 1.2.0-0ubuntu0.16.04.2, shutdown, started up, suspended resumed, and still see this issue.

I'm sorry, I haven't had more time to debug this myself.

Revision history for this message
maarten (info-maartenabbring) wrote :

Happening on an Asus N53 laptop. (AR9285 Wireless network adapter). Problem is annoying to consider rolling back to previous version. Not an easy job. Didn't have to do that in many years of upgrading.

Revision history for this message
monte (monte3) wrote :

Have this bug on fresh install on Lenovo x230t, Intel 6205 card. Have to restart nm-applet after every suspend. It seems that restart of network-manager service produces same bug to applet. I mean doing "sudo service network-manager restart" brokes nm-applet, so I need to restart it manually.

Revision history for this message
Dave Chiluk (chiluk) wrote :

This appears to be getting some progress via 1585863, so I'm marking it as a dupe, even though this one is older.

Revision history for this message
Dave Chiluk (chiluk) wrote :

I went tested the patches for 1585863, but still saw the issue.

Revision history for this message
Dave Chiluk (chiluk) wrote :

@cyphermox

Here's the debug output we worked on today. I removed most everything from before I suspended the machine. Everything remaining is either from the suspend or the resume.

The output was achieved by adding --log-level=debug to /lib/systemd/system/NetworkManager.service at the ExecStart= line, and then restarting.

Revision history for this message
Dave Chiluk (chiluk) wrote :

So I don't seem to be able to reproduce this any more. I did recently boot windows on my laptop, and then ran updates. I no longer seem to be able to reproduce this issue.

One of the important updates was an update to the IMEI firmware on my machine. Can someone else on this bug please upgrade your IMEI firmware *(which likely needs to be performed via windows), and then attempt to reproduce this bug. I'd like confirmation that the IMEI firmware update did indeed resolve this issue.

Thanks

Revision history for this message
monte (monte3) wrote :

IMEI firmware update for wifi card? Do they even have IMEI, never heard of it.

Revision history for this message
Nick Kleeman (kleeman7) wrote :

I think the IMEI firmware is a fluke, plus that is not really a solution for everyone as it is just a windows driver, and not everyone is dual booting. It's "Intel Management Engine Interface" only reference I can find to "IMEI" that makes sense.

On a side note, I just deleted my windows partition about a week ago and was up to date of the time, also on Dell's website the IMEI is from February 2016.

Revision history for this message
Dave Chiluk (chiluk) wrote :

There is a firmware component for IMEI. If I'm not mistaken the IMEI firmware is what is responsible for vpro / AMT functionality. According to this FAQ https://software.intel.com/en-us/articles/intel-vpro-technology-faq, it is capable of controlling a wireless card even while in sleep states. This could be putting the card in an unexpected state while in suspend/sleep.

The update I installed was not simply a windows driver update, but actually a firmware flash presumably for the formentioned vpro/amt functionality.

That being said if your machines are not vpro/amt capable then that's clearly not your issue, but until I hit that issue again it does seem to be what resolved my issue.

Revision history for this message
monte (monte3) wrote :

Ok, thanks for a hint. Found Intel Management Engine Firmware 8.1 for my lenovo x230t, installed it on Windows 7, rebooted into Ubuntu, but bug is still present, same as it was before.

Revision history for this message
Dave Chiluk (chiluk) wrote :

@monte

Alright thanks for the test. Can you please add --log-level=debug to /lib/systemd/system/NetworkManager.service at the end of the ExecStart= line. So it looks like this
ExecStart=/usr/sbin/NetworkManager --no-daemon --log-level=debug
Then
- restart your machine.
- suspend the machine.
- resume the machine. Verifying that you hit the issue.
- Then upload your syslog as I did above.

Thank you,
Dave

Revision history for this message
monte (monte3) wrote :

Here is my syslog after resume. Sorry for so long time without reply.
And there are errors in log related to bluez service, as it don't work properly after suspend either, so I need to use script to restart it automatically on resume.

Revision history for this message
Dave Chiluk (chiluk) wrote :

Not a duplicate of 1585863, as
$ sudo wpa_cli scan
does not recover nm-applet functionality. There seem to be a number of similar but different issues related to wifi.

Dave Chiluk (chiluk)
summary: - Network manager unable to control wifi after suspend in 16.04
+ Network manager applet unable to control wifi after suspend in 16.04
Revision history for this message
Ebrael (ebraelshaddai) wrote :

I just tested a simple script (called "network_restar") to make NM restart upon resume... and IT HAS WORKED!

Rather than creating it via terminal right into the relative folder (/lib/systemd/system-sleep), I did it thru text editor, saved it in Home and moved it to that folder as sudo.

>> Script content:

case "${1}" in
  resume|thaw)
    sudo service network-manager restart
;;
esac

>> After this, run (line by line, supposing you have saved script your Home dir):

sudo su
(type your root password!)

mv network_restart /lib/systemd/system-sleep

chmod +x /lib/systemd/system-sleep/network_restart

>> Script seen on: http://askubuntu.com/questions/766718/script-to-restart-network-manager-after-resume-from-sleep

Revision history for this message
DocWilco (k-ubuntuone-m) wrote :

I too am affected by this bug. Is there anything I can do to help debug/solve this?

Revision history for this message
Peter S (peter-sevemark) wrote :

This temporary solution seems to work for me:

sudo systemctl restart network-manager.service

Got it from http://askubuntu.com/questions/761180/wifi-doesnt-work-after-suspend-after-16-04-upgrade

Revision history for this message
jkyamog (jkyamog) wrote :

as a temporary work around I put a script here:

/etc/pm/sleep.d/99_restart_network_manager

That contains:

#! /bin/sh

case $1 in
     suspend|suspend_hybrid|hibernate)
        service network-manager restart
        ;;
     resume|thaw)
        # No need to do anything here
        :
        ;;
esac

Revision history for this message
Rob Frohne (frohro) wrote :

I find that I can:

$ killall nm-applet && nm-applet&

and it is back working. I haven't been successful getting that to work in a script upon resume yet though.

Revision history for this message
Tambellini (william-tambellini) wrote :

Same bug on Alienware 17 R4 running ubuntu 16.04 LTS kernel 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux.
sudo service network-manager restart
does fix it.
Still no official fix though ?

Revision history for this message
ComputersHowtoGeek (computershowtopro) wrote :

One year later (well, roughly), and Peppermint 7, same bug, happens only sometimes, after logging in, doesn't matter whether it's from a suspended session, or logged out fully, even after a complete reboot;
sometimes nm-applet loads without any error, sometimes it displays:
(nm-applet:2962): nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed

Any chance somebody has a fix for this ? I don't mind if it's an unofficial fix, as long as it works. It delays my work a lot, and I'd really like to fix this somehow.

Thank you

Revision history for this message
Shih-Yuan Lee (fourdollars) wrote :

What's the output of `nmcli d` when the problem happens?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.