NetworkManager failed to function after suspend and resume

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

Adding interesting log excerpt from a duplicate bug, it's the same symptom here:

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.

Can either of these patches make a difference?

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a687d1f9e0f75b987f40335934b54aa748f6724b

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/src/nm-manager.c?id=5f04324f8bef43ebe831a6fa20ea8577dcad0ac5

pitti, will you build packages with these patches or should I test them in my local machine?

Fran, the first patch looks promising. The second patch looks unrelated, but cherry-picking it can't hurt anyway I guess. If you can test this, please do (I just returned from holidays and have a giant backlog).

The first patch above does nothing to the bring the connection back up after building my own set of packages. There does seem to be a race condition of some sort between the supplicant and NM but I'm not able to track it down appropriately.

I'm attaching my debug logs to this bug report in the hope that someone can point me in the right direction.

This same bug happens on a Macbook pro 8,1 with Ubuntu unity 15.04
After a suspend the wifi is disconnected. Restarting the network-manager or toggling wifi off/on via the system tray solves the problem. This does not improve the user experience.

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.

The workaround is to switch to upstart by default.
Can be done like this:

Install the upstart-sysv package, which will remove ubuntu-standard and systemd-sysv (but should not remove anything else -- if it does, yell!), and run sudo update-initramfs -u. After that, grub's "Advanced options" menu will have a corresponding "Ubuntu, with Linux ... (systemd)" entry where you can do an one-time boot with systemd.

https://wiki.ubuntu.com/SystemdForUpstartUsers

Recently moved to Archlinux and this bug is not present here anymore.

Same problem on Lenovo E145 with BCM43228 wifi. Reconnecting by turning wifi off and on sometimes works. Have not tried restarting networkmanager.

Reconnecting wifi worked fine here until the system upgrade to 15.04 (vivid). Since then, after suspend and resume wifi does not work almost always.

No wifi networks are shown in the network manager menu then, and I have to either switch networking completely off and on again, or select “connect to hidden nework…” and choose the desired SSID there. This is really annoying, and I'm thinking about switching to another distro because of this (and bug 1268257).

But this happens only on an Acer Laptop, not on another one from Lenovo.

$ lspci -v -s 4:0.0
04:00.0 Network controller: Broadcom Corporation BCM43228 802.11a/b/g/n
 Subsystem: Foxconn International, Inc. Device e04b
 Flags: bus master, fast devsel, latency 0, IRQ 18
 Memory at b3500000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: <access denied>
 Kernel driver in use: wl

Have I found the correct bug report, or should I file a new one?

Is there any better workaround than the mine?

I have same issue with Macbook 4,1 (Early 2008).

I noticed same symptom as Martin (activated -> unmanaged after resume) and looking network manager code (do_sleep_wake() in nm-manager.c) it seems to be related to wake on lan stuff.

So, I modified nm_platform_link_get_wake_on_lan() to always return FALSE for wifi and with that change wifi is resumed after sleep.

Timing change is probably just hiding the real bug, so this is more of an ugly hack than proper workaround.

This sounds similar to bug 1450396. Could you try and add this line

  ethtool -s eth0 wol g

to /etc/rc.local before the "exit 0", reboot, and see if that helps?

I tried this, but it didn't help for me. I don't have wired LAN in use (eth0 is not connected), so I also tried to adapt change for wlan0, but ethtool doesn't give any info for wlan0 and setting wol mode doesn't work:

$ sudo ethtool wlan0
Settings for wlan0:
No data available

Based on network manager prints in journal, I can see that it takes the branch with "device_is_wake_on_lan" for wlan0 disabling device *after* resume. So, it might be that wol support/status is somehow incorrectly defined (I'm not trying to use wake on wlan):

kesä 16 18:41:48 juha-MacBook NetworkManager[670]: <info> wake requested (sleeping: yes enabled: yes)
kesä 16 18:41:48 juha-MacBook NetworkManager[670]: <info> waking up...
kesä 16 18:41:48 juha-MacBook NetworkManager[670]: <info> (wlan0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
kesä 16 18:41:48 juha-MacBook NetworkManager[670]: <info> (wlan0): deactivating device (reason 'sleeping') [37]

After forcing nm_platform_link_get_wake_on_lan() to return false for wifi:
heinä 14 23:04:19 juha-MacBook NetworkManager[685]: <info> wake requested (sleeping: yes enabled: yes)
heinä 14 23:04:19 juha-MacBook NetworkManager[685]: <info> waking up...
heinä 14 23:04:19 juha-MacBook NetworkManager[685]: <info> (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [
heinä 14 23:04:19 juha-MacBook NetworkManager[685]: <info> (wlan0): preparing device

Used kernel driver is wl:
$ lspci -v -s 2:0.0
02:00.0 Network controller: Broadcom Corporation BCM4321 802.11a/b/g/n (rev 03)
 Subsystem: Apple Inc. AirPort Extreme
 Physical Slot: 4
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at 90500000 (64-bit, non-prefetchable) [size=16K]
 Memory at 90000000 (64-bit, prefetchable) [size=1M]
 Capabilities: <access denied>
 Kernel driver in use: wl

The workaround I am currently using is to use the b43-driver instead of wl (sudo rmmod wl ; sudo modprobe b43). This means forgoing support for 802.11n, I think. At least I can no longer see 5GHz networks. However, it also means that the network reliably reconnects after suspend and resume, in my experience.

(Hardware: 13" Retina MacBook Pro, software: Kubuntu 15.04)

Haha, one year and a half and there is no importance! Awesome!

Twente, that's because this bug is useless for fixing any issues -- I originally filed the bug with 13.10, which has been EOL for 1.5 years. Others added completely unrelated bugs here along the way rather than filing new bugs for their issues. Once this turned into a wasteland of unrelated information, there's no need to look at this bug again, and indeed, my original issue has been fixed in 14.04 LTS for ages now. I have no idea if the other unrelated bugs here have ever been addressed.

This issue has been present again with systemd on Ubuntu 15.04. I have a clean install of 15.04 on a Lenovo Y50-70 with an Intel Wi-Fi AC 7260 and I need to run "sudo service network-manager restart" in order to bring back internet access. This issue was not present with 14.10 and before. I first found the solution on http://ubuntuforums.org/showthread.php?t=2223566 . It would be great if this would be fixed, as it is quite annoying. But then again, this is OSS, so I have no hopes for this issue.

Andre, as I described in the previous comment, this bug is now useless because it has been abused for too many tasks.

Please file a new bug, so that your logs and information can be collected.

Thanks.