WiFi doesn't work after resume

Bug #1187005 reported by Julien Olivier
72
This bug affects 15 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Incomplete
Medium
Unassigned

Bug Description

After resuming from suspend, the WiFi doesn't work any more. Clicking on the network applet, I can see that WiFi is disabled, but after enabling it, it disabels itself again immediately.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: network-manager 0.9.8.0-0ubuntu9~raring2 [origin: LP-PPA-gnome3-team-gnome3-staging]
ProcVersionSignature: Ubuntu 3.8.0-24.35-generic 3.8.13
Uname: Linux 3.8.0-24-generic i686
ApportVersion: 2.9.2-0ubuntu8.1
Architecture: i386
Date: Mon Jun 3 16:13:43 2013
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2010-09-15 (991 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release i386 (20100816.1)
IpRoute:
 default via 192.168.0.254 dev wlan2 proto static
 169.254.0.0/16 dev wlan2 scope link metric 1000
 192.168.0.0/24 dev wlan2 proto kernel scope link src 192.168.0.12 metric 9
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
MarkForUpload: True
NetworkManager.state:
 [main]
 WirelessEnabled=true
 NetworkingEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to raring on 2011-04-01 (794 days ago)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth2 802-3-ethernet unavailable /org/freedesktop/NetworkManager/Devices/1
 wlan2 802-11-wireless connected /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

Revision history for this message
Julien Olivier (julo) wrote :
Revision history for this message
Julien Olivier (julo) wrote :

Another thing: if i suspend using "sudo pm-suspend", the WiFi still works when I resume.

Revision history for this message
Julien Olivier (julo) wrote :

Actually, I found an even simpler work-around: just after resume, I just have to do "sudo killall NetworkManager", and my network comes back. So I guess the bug is definitely in NetworkManager.

Revision history for this message
Julien Olivier (julo) wrote :
Revision history for this message
Julien Olivier (julo) wrote :

OK, forget about about my last comment: the solution mentionned in the link doesn't work for me, so I guess it's a different bug.

Revision history for this message
Julien Olivier (julo) wrote :

Now, I've tried installing the proprietary driver for my wifi adapter, and the bug is still there. So I guess it's definitely not a driver bug.

By the way, is anyone reading my comments? Is there anything I could do to help you fix it? It's a real showstopper!

Revision history for this message
Julien Olivier (julo) wrote :

Seems like NetworkManager never receives the "wake up" signal... Who's responsible for sending it?

(snip)
NetworkManager[21778]: <info> Policy set 'Auto XXXXX' (eth3) as default for IPv4 routing and DNS.
NetworkManager[21778]: <info> DNS: starting dnsmasq...
NetworkManager[21778]: <warn> dnsmasq not available on the bus, can't update servers.
NetworkManager[21778]: <error> [1370694157.41643] [nm-dns-dnsmasq.c:402] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name
NetworkManager[21778]: <warn> DNS: plugin dnsmasq update failed
NetworkManager[21778]: <info> Writing DNS information to /sbin/resolvconf
NetworkManager[21778]: <info> Activation (eth3) successful, device activated.
NetworkManager[21778]: <warn> dnsmasq appeared on DBus: :1.273
NetworkManager[21778]: <info> Writing DNS information to /sbin/resolvconf
NetworkManager[21778]: <info> sleep requested (sleeping: no enabled: yes)
NetworkManager[21778]: <info> sleeping or disabling...
NetworkManager[21778]: <info> (eth3): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
NetworkManager[21778]: <info> (eth3): deactivating device (reason 'sleeping') [37]
NetworkManager[21778]: <info> (eth3): canceled DHCP transaction, DHCP client pid 21803
NetworkManager[21778]: <warn> DNS: plugin dnsmasq update failed
NetworkManager[21778]: <info> Removing DNS information from /sbin/resolvconf
NetworkManager[21778]: <info> (eth3): cleaning up...
NetworkManager[21778]: <info> (eth3): taking down device.
NetworkManager[21778]: <info> (eth2): device state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]
NetworkManager[21778]: <info> (eth2): cleaning up...
NetworkManager[21778]: <info> (eth2): taking down device.

Revision history for this message
Julien Olivier (julo) wrote :

I'm not the only one: http://ubuntuforums.org/showthread.php?t=1433604
Please take this bug into consideration...

Revision history for this message
Julien Olivier (julo) wrote :

I've just found this entry in pm-utils' changelog:

pm-utils (1.4.1-9git1) raring; urgency=low

  Upload current Debian packaging git head.

  * debian/rules: Stop installing sleep.d/55NetworkManager. Current
    NetworkManager does not even expose this API any more, so the
    sleep()/wake() calls just always fail. As NM is apparently able to deal
    with suspends just fine, no need to waste cycles on this.

I guess that systemd-logind sends the "sleep" signal to network-manager, but network-manager never sends back the "wake" signal. So, the solution would be to just stop sending the "sleep" signal to network-manager on suspend.

PS: Am I talking to myself ? :)

Revision history for this message
dclee9 (dclee9) wrote :

i have the same problem too, but running the command "sudo killall NetworkManage" doesn't bring the wifi network back on.

my situation is i can see the nearby AP, but wasn't able to connect to them, the AP shown are correct.

i ran into this problem during Linux mint 13 (ubuntu 12.04 based) and linux mint 15, but when i install official ubuntu 12.04, there is no such problem.

in ubuntu 12.04, my wifi works after suspend.

my hardward is intel centrino 1000 n

Revision history for this message
C de-Avillez (hggdh2) wrote :

@all: if you change the status of a bug, or mark/unmark it as a duplicate, please *explain*, in a comment, why you are doing it. Certainly, if you think this is a wrong duplicate, you have some reasoning that may help us understand what happened.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Revision history for this message
penalvch (penalvch) wrote :

Unmarked as a duplicate as this was initially marked a duplicate with no indication this is such. As well, if something is happening after a resume, this would indicate a kernel bug in a driver causing this, versus userspace. Please do not mark this a duplicate again unless you can make a precise technical analysis on what commit would be causing this issue.

Thank you for your understanding.

Julien Olivier, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one all the way at the bottom) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue.Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.12-rc7

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Changed in linux (Ubuntu):
status: New → Confirmed
penalvch (penalvch)
affects: ubuntu-gnome → linux (Ubuntu)
Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Julien Olivier (julo) wrote :

@penalvch: the bug I reported is definitely the same as bug #1184262. The symptoms, at least, are exactly the same, and the fix provided in bug #1184262 works for me too. That's why I marked this bug as a duplicate of bug #1184262. Now, if you really insist on this bug not being a duplicate of #1184262, feel free to keep this one opened, but I'm not going to bother investigating any more, as the problem is now fixed for me thanks to the updated package provided on bug #1184262.

Thanks.

Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Martin Pitt (pitti) wrote :

This is rather clearly a duplicate of the logind/systemd-shim bug, re-duplicating.

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

Other bug subscribers

Remote bug watches

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