NetworkManager failed to function after suspend and resume

Bug #1270257 reported by Seth Arnold on 2014-01-17
206
This bug affects 42 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Undecided
Unassigned

Bug Description

NetworkManager failed to function after resuming from suspend. The indicator applet in the Mac OS style menu bar showed the empty quarter-circle, and clicking "Enable Networking" didn't change the menu options or the style of the applet. Running "sudo service network-manager restart" brought back functionality.

$ dpkg -l systemd* logind*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-======================-================-================-==================================================
un logind <none> (no description available)
un systemd <none> (no description available)
ii systemd-services 204-0ubuntu19.1 amd64 systemd runtime services
ii systemd-shim 6-0ubuntu0.13.10 amd64 shim for systemd

Thanks

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: network-manager 0.9.8.0-0ubuntu22
ProcVersionSignature: Ubuntu 3.11.0-15.23-generic 3.11.10
Uname: Linux 3.11.0-15-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
Date: Fri Jan 17 10:08:48 2014
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2012-10-18 (456 days ago)
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1)
IpRoute:
 default via 192.168.1.1 dev wlan0 proto static
 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.14 metric 9
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
MarkForUpload: True
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to saucy on 2013-11-06 (72 days ago)
modified.conffile..etc.NetworkManager.NetworkManager.conf: [modified]
mtime.conffile..etc.NetworkManager.NetworkManager.conf: 2013-11-05T17:49:23
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 wlan0 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/1
 eth0 802-3-ethernet unavailable /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.8.0 connected enabled enabled enabled enabled disabled

Seth Arnold (seth-arnold) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) wrote :

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.

Fran Diéguez (frandieguez) wrote :

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

Martin Pitt (pitti) wrote :

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).

Emil Soleyman (emilsoleyman) wrote :

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.

Benni (benjaminf-bauer) wrote :

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.

Bluegrassin (anderslgade) wrote :

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.

Mentis (mentis-by) wrote :

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

Fran Diéguez (frandieguez) wrote :

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

Vegard (skvate) wrote :

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

Stephan Springer (geryon) wrote :

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?

Juha Toivonen (juhavt) wrote :

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.

Martin Pitt (pitti) wrote :

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?

Juha Toivonen (juhavt) wrote :

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

Magnus Hoff (maghoff) wrote :

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)

Unixuser (unixuser) wrote :

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

Changed in network-manager (Ubuntu):
status: Confirmed → Invalid
Seth Arnold (seth-arnold) wrote :

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.

Andrei (andrei-doom) wrote :

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.

Seth Arnold (seth-arnold) wrote :

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.

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

Other bug subscribers