No wifi connection after suspend with systemd due to missing "wpa_cli suspend"

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

i experience similar.

I presume our resume/suspend integration is not in place?

It is in place, this is working fine here and for other people. After a suspend/resume cycle, can you please run

  journalctl -b -u NetworkManager > /tmp/nm.log

and attach /tmp/nm.log here?

Here is the log file

 - Mar 10 00:37:22, laptop lid closed
 - Mar 10 10:04:24, laptop lid opened
 - Mar 10 10:06:42, opened g-c-c and switch Wifi off and back on again

Now my wireless connection works.

Thanks for the log. Putting the interesting excerpt here for convenience:

Mar 09 23:27:59 fry NetworkManager[1000]: <info> (wlan0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Mar 09 23:27:59 fry NetworkManager[1000]: <info> NetworkManager state is now CONNECTED_LOCAL
Mar 09 23:27:59 fry NetworkManager[1000]: <info> NetworkManager state is now CONNECTED_GLOBAL
[...]
Mar 10 00:37:20 fry NetworkManager[1000]: <info> sleep requested (sleeping: no enabled: yes)
Mar 10 00:37:20 fry NetworkManager[1000]: <info> sleeping...
Mar 10 10:04:24 fry NetworkManager[1000]: <info> waking up...
Mar 10 10:04:24 fry NetworkManager[1000]: <info> (wlan0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
Mar 10 10:04:24 fry NetworkManager[1000]: <info> (wlan0): deactivating device (reason 'sleeping') [37]

So it seems that the "activated -> unmanaged" action should be done *before* "sleeping...", and then it just forgets to bring it back up after waking up. Here it has the correct order, so that sounds like a race condition.

This part (logind interaction) hasn't actually changed in quite some time. Out of interest, do you get this error under upstart too? This doesn't actually sound specific to using systemd as init, but it would be nice to confirm that. Otherwise it's another data point for debugging this. Thanks!

Ah, this was indeed reported before already, also under upstart. Duplicating/untagging.

No, I don't get this error under upstart

Same here, I didn't have this issue in 14.10, only in 15.04.

Happening to me starting from migration to systemd. Haven't seen this on upstart.

Commenting here since it seems more active than the thread it's supposed to be a duplicate of:

I just installed 15.04 on a lenovo E330 with a r8169 wireless chip and have this problem. Wifi connecting on startup, but after suspend, I have to deactivate wireless and reactivate to get a connection. Never had the problem with neither 14.04 nor 14.10.

Same problem her on a new installation of ubuntu 15.04. I encrypted my root partition during installation. Wifi stops working after resuming from sleep (I close the lid). This didn't happened on earlier versions of ubuntu.

I see the same behavior (Kubuntu 15.04) and my NetworkManager log output has the same backwards ordering where "activated -> unmanaged" happens after "sleeping...".

Adding the comment here since the solution only appears in the duplicate thread:
The workaround that works for me is to switch Ubuntu 15.04 to upstart.
Thanks to Mentis for the original post.

Problem still exists in Wily.

Reconnect after resume works after switching to upstart as suggested, but there is still no Wifi connection after turning Wifi off in the panel menu and back on later.

The main difference in this regard between upstart and systemd is that during suspend the pm-utils quirks are not run any more. Can you please check (under systemd) that running "sudo pm-suspend" instead of closing the lid or using the indicator fixes this problem?

I'm fairly sure that it does. If so, then we need to find the particular hook that is responsible for this. The most probable one is 60_wpa_supplicant. Can you see if this works:

  sudo wpa_cli suspend ; sudo systemctl suspend; sudo wpa_cli resume

?

First post here, just thought I could chime in since this issue affects me as well.

Running either "sudo pm-suspend" or the 2nd group of commands fixes this issue under systemd in 15.04. After resuming from a suspend (either from a closed lid or being AFK long enough for it to happen), when my wifi did not reconnect, I tried both commands. For both of them, my computer re-entered suspend, but after pressing a key to resume and entering my password, the wifi reconnected as expected.

Martin,

That series of commands works for me. Wifi came back up without any issues.

Thanks for confirming! So let's call the "wpa_cli suspend" hook for now. Judging by the upstream NM bug this is certainly not the only cause here, there's also some driver bugs here. But this should at least fix the issue for some reporters.

I uploaded this to xenial, and to the wily SRU review queue.

Wrong package; fixed in xenial in https://launchpad.net/ubuntu/+source/wpa/2.4-0ubuntu4

Hello Fran, or anyone else affected,

Accepted wpa into wily-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/wpa/2.4-0ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

The updated wpa package 3.1 doesn't solve this issue.
After pm-suspend or when I close the lid, wifi is coming back not with a resume from the menu.

@stef: OK, I unduplicated your bug 1492850, let's continue the debugging there.

As a part of the Stable Release Updates quality process a search for Launchpad bug reports using the version of wpa from wily-proposed was performed and bug 1516265 was found. Please investigate this bug report to ensure that a regression will not be created by this SRU. In the event that this is not a regression remove the "verification-failed" tag from this bug report and add the tag "bot-stop-nagging" to bug 1516265 (not this bug). Thanks!

Bug 1516265 is not a regression, it looks like a local misconfiguration. I followed up there.

Can folks who are affected by this please check if this update fixes resuming, so that we can release this fix?

wpasupplicant 2.4-0ubuntu3.2 installed and wifi not comming back from suspend.

I have been running 15.10 for about a month now, without this problem (or any other problems).

This issue has suddenly occurred, and, to me, seems like a regression from a relatively recent update. No other parameters, that I know of, have changed (same computer, WiFi, OS version).

I have wpasupplicant 2.4-0ubuntu3.2, but I do not know if this is relevant to my issue.

After a bit of fiddling, it seems that this problem is intermittent.

@nikolajsheller
I don't agree. The bug occurs frequently and increases the login time which is very annoying.

@garnus
We might be seeing different issues...
I'm using an Asus UX32VD with an Intel Centrino Advanced-N 6235 (rev 24) in the 5Ghz band.

@nikolajsheller
Dell Latitude e5450 with Intel Corporation Wireless 7265.

I'm seeing exactly the same problem

 $ sudo dmidecode | grep Product | head -1
        Product Name: Inspiron 7548

$ uname -a
Linux hawk 4.3.0-040300-generic #201511020949 SMP Mon Nov 2 14:50:44 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a 2>/dev/null
Distributor ID: Ubuntu
Description: Ubuntu 15.10
Release: 15.10
Codename: wily

Same issue for me on Lenovo Yoga 2 11 running Ubuntu 15.04 and systemd .
01:00.0 Network controller: Broadcom Corporation BCM43142 802.11b/g/n (rev 01)

Funny thing I noticed is that if I close the lid again and open it again, it does work again

When should we see a fix in the repos?

Hi
I run a upgrade to 16.04 and this bug still occurs.

I have the same bug. Ubuntu 15.10 \n \l under Dell E5450

I am also experiencing this bug on 16.04.

Hardware is a Thinkpad X230 with an Intel Corporation Centrino Advanced-N 6205 wifi card.

I'm facing the same bug while running 16.04 on a Dell Vostro 3558 (iwlwifi).

I edited the file /lib/systemd/system-sleep/wpasupplicant and changed the bit that goes '/sbin/wpa_cli resume ;;' to 'systemctl restart network-manager.service ;;'. Now when I resume from suspend, at first the network is disabled but in a few seconds, network manager restarts and my wi-fi connection reconnects.

The logs confirm this:
Apr 24 13:58:04 prashant-Vostro-3558 NetworkManager[806]: <info> [1461486484.8054] manager: sleep requested (sleeping: no enabled: yes)
Apr 24 13:58:04 prashant-Vostro-3558 NetworkManager[806]: <info> [1461486484.8055] manager: sleeping...
Apr 24 13:58:04 prashant-Vostro-3558 NetworkManager[806]: <info> [1461486484.8056] device (wlp6s0): state change: activated -> unmanaged (reason 'sle
Apr 24 13:58:04 prashant-Vostro-3558 NetworkManager[806]: <info> [1461486484.8176] dhcp4 (wlp6s0): canceled DHCP transaction, DHCP client pid 2045
Apr 24 13:58:04 prashant-Vostro-3558 NetworkManager[806]: <info> [1461486484.8176] dhcp4 (wlp6s0): state changed bound -> done
Apr 24 13:58:04 prashant-Vostro-3558 NetworkManager[806]: <info> [1461486484.8295] dns-mgr: Writing DNS information to /sbin/resolvconf
Apr 24 13:58:04 prashant-Vostro-3558 dnsmasq[2152]: setting upstream servers from DBus
Apr 24 13:58:04 prashant-Vostro-3558 NetworkManager[806]: <info> [1461486484.8405] manager: NetworkManager state is now ASLEEP
Apr 24 15:45:56 prashant-Vostro-3558 NetworkManager[806]: <info> [1461492956.5797] manager: WiFi now disabled by radio killswitch
Apr 24 15:45:56 prashant-Vostro-3558 systemd[1]: Stopping Network Manager...
Apr 24 15:45:56 prashant-Vostro-3558 NetworkManager[806]: <info> [1461492956.6291] caught SIGTERM, shutting down normally.
Apr 24 15:45:56 prashant-Vostro-3558 NetworkManager[806]: <info> [1461492956.6301] device (enp7s0): state change: unavailable -> unmanaged (reason 'u
Apr 24 15:45:56 prashant-Vostro-3558 NetworkManager[806]: <info> [1461492956.6542] exiting (success)
Apr 24 15:45:56 prashant-Vostro-3558 systemd[1]: Stopped Network Manager.
Apr 24 15:45:56 prashant-Vostro-3558 systemd[1]: Starting Network Manager...
Apr 24 15:45:56 prashant-Vostro-3558 systemd[1]: Started Network Manager.
Apr 24 15:45:56 prashant-Vostro-3558 NetworkManager[6370]: <info> [1461492956.7194] NetworkManager (version 1.1.93) is starting...

I confirm the bug is present on my Dell XPS13 (2014) under Ubuntu 16.04 as well.

I also confirm that Prashant L Rao's solution seems to have solved the sleep/restore problem.

Same here: Dell XPS13 L322X and the Prashant L Rao's solution worked for me too.

I confirm the bug is present on my ThinkPad X201 under Ubuntu 16.04 as well;

solved through:

http://askubuntu.com/questions/452826/wireless-networking-not-working-after-resume-in-ubuntu-14-04

Says fix released for xenial. What was it actually released in? wpa_supplicant? I still have the problem intermittently.

May 16 22:58:18 bryan-Latitude-E6410 kernel: iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
May 16 22:58:19 bryan-Latitude-E6410 kernel: IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
May 16 22:58:19 bryan-Latitude-E6410 NetworkManager[690]: <info> [1463453899.0483] device (eno1): state change: unmanaged -> unavailable (reason 'managed') [1
May 16 22:58:19 bryan-Latitude-E6410 kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
May 16 22:58:19 bryan-Latitude-E6410 NetworkManager[690]: <info> [1463453899.2606] manager: NetworkManager state is now DISCONNECTED
May 16 22:58:19 bryan-Latitude-E6410 kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
May 16 22:58:19 bryan-Latitude-E6410 wpa_supplicant[858]: dbus: wpa_dbus_get_object_properties: failed to get object properties: (none) none
May 16 22:58:19 bryan-Latitude-E6410 wpa_supplicant[858]: dbus: Failed to construct signal
May 16 22:58:19 bryan-Latitude-E6410 NetworkManager[690]: <info> [1463453899.3049] device (wlp3s0): supplicant interface state: starting -> ready
May 16 22:58:19 bryan-Latitude-E6410 NetworkManager[690]: <info> [1463453899.3050] device (wlp3s0): state change: unavailable -> disconnected (reason 'supplic
May 16 22:58:19 bryan-Latitude-E6410 kernel: IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
May 16 22:58:20 bryan-Latitude-E6410 acpid[617]: client connected from 8954[0:0]
May 16 22:58:20 bryan-Latitude-E6410 acpid[617]: 1 client rule loaded
May 16 22:58:20 bryan-Latitude-E6410 kernel: dell_wmi: Unknown WMI event type 0x11: 0xffd1

sudo service network-manager restart seems to fix the problem as suggested above.

I also still have the problem in Xenial on a Dell latitude e6420

I am still seeing this issue as of today (2016-05-22) on Ubuntu 16.04.
Laptop: Asus UX32VD
Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24)

The problem is intermittent. Networking after resume works ~9 times out of 10.
Did not have this issue on 15.10 with the same hardware.

I'm having the listing issue in Ubuntu 16.04. So after suspend the wifi is connected but i'm not able to see the available connection nor choose a connection.The packages installed are:

1- network-manager/xenial,now 1.1.93-0ubuntu4 amd64 [installato, automatico]
  network management framework (daemon and userspace tools)

2- network-manager-gnome/xenial-updates,now 1.2.0-0ubuntu0.16.04.1 amd64 [installato, automatico]
  network management framework (GNOME frontend)

I started experiencing this bug after upgrading a Dell XPS 13 2013 (Haswell) to 16.04 and systemd.
After a resume, I have to do one of two things to re-connect to wifi:

  1. Manually re-enable wifi in NetworkManager menu
  2. sudo systemctl restart NetworkManager

This fix works for me:

1. As root, create a file named /etc/systemd/system/resume.service with the following contents:

[Unit]
Description=Local system resume actions
After=suspend.target

[Service]
Type=oneshot
ExecStart=/bin/systemctl restart NetworkManager.service

[Install]
WantedBy=suspend.target

####################

    sudo systemctl enable resume.service
    sudo systemctl daemon-reload

Now after a suspend resume, I the Network Manager icon reloads almost instantly, and wifi comes back.

You can confirm the action ran by checking it's service log after a resume:

 journalctl -u resume.service

Jun 01 11:29:11 myhost systemd[1]: Starting Local system resume actions...
Jun 01 11:29:12 myhost systemd[1]: Started Local system resume actions.

If you want to trigger other actions to run at "resume" time, you can add additional "ExecStart=" lines to the file.

I am also affected by this bug. It only occurs in ~1 out of 3 suspend/resumes and can be fixed by sudo systemctl restart NetworkManager. I am using ubuntu 16.04, with all updates available until today. My hardware is a thinkpad t440s with the following wlan card Intel Corporation Wireless 7260 (rev 83).

This happens to me in maybe 1 of 15 suspend/resume cycles on Thinkpad T430 running 64 bit Xubuntu 16.04.

Same issue for me, Dell XPS 13 (2014 I think?), running 16.04 with all updates. Mark Stosberg's process (#50) fixes it. I realise it's a hack, but it works - would it make sense to put this in as a fix in the meantime, given the issue has been open for nearly a year and a half?

Aberto

This is marked as "fixed", but what was the fix?

Same issue for me, Dell Latitude E5450 running 16.04 with all updates. Wifi is sometimes (~1 in 4 times?) disabled after resume. The fix in post #50 above worked for me. This bug is marked "fixed", what is the accepted fix?

Martin Pitt committed some fix in October 2015, but apparently that did not solve this bug, or only partly.

What's the correct way to handle this? Reopen this bug or open a new one referring to this one?

This still happens for me, too (Ubuntu 16.04), and the workaround from #50 fixes it.

Stephan, it's almost always better to file a new bug than to tack a conversation onto an old bug.

Thanks

@pitti: your fix still doesn't work all the time. It still happens once in ~10 times.

@makuser: Please open a new bug referring to this bug and add a comment with the new bug number here. Thanks.

Debian users complain this doesn't always work: http://bugs.debian.org/835648

I am running 16.04 LTS on a MacBook Pro and it is dropping the nm-applet icon after a resume. I have a suspicion that it was reliable until I created a second user on the computer. Then it would appear for one person and not the other, and when produced in the other it disappeared from the previous user. I thought I had it solved but then when I left it a while and it had to wake up and resume the Icon was gone again. I have a suspicion that permissions are involved, the setup for nm-applet appears to be written for only one user to access it?? The rest should just accept it? At least I have it reliably beginning on a cold boot for either user or swap of user, but not resume apparently. I think my attempts (successful to some degree) have only been superficial and not getting at the heart of matter.

Just installed Ubuntu 16.10 on my MacBook Pro. I have this bug 100% of the time and can recover the wifi by restarting the NetworkManager service.

This bug doesn't seem to be fixed in Yakkety.

Creak, this bug has grown too large with too many "me too" complaints to be useful. I suggest filing a new bug with ubuntu-bug network-manager and describe what you see afresh.

Thanks

Done! See bug 1676081.

Thanks Seth