WiFi malfunction after suspend & resume stress - sudo wpa_cli scan required to fix it.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OEM Priority Project |
Fix Released
|
Critical
|
Unassigned | ||
Xenial |
Fix Released
|
Critical
|
Unassigned | ||
network-manager (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
HOW TO REPRODUCE:
1. Install fwts by `sudo apt-get install fwts`.
2. Run the suspend & resume stress test.
sudo fwts s3 --s3-multiple=30 --s3-min-delay=5 --s3-max-delay=5 --s3-delay-delta=5
RESULT:
The WiFi can not connect to any access point and we have to execute `sudo wpa_cli scan` manually to make it work again.
WORKAROUND:
(http://
SYSTEM INFO:
Description: Ubuntu Yakkety Yak (development branch)
Release: 16.10
Packages:
libnm-glib-
libnm-glib4:amd64 1.2.2-0ubuntu2
libnm-util2:amd64 1.2.2-0ubuntu2
libnm0:amd64 1.2.2-0ubuntu2
network-manager 1.2.2-0ubuntu2
Shih-Yuan Lee (fourdollars) wrote : | #1 |
tags: | added: xenial yakkety |
Ubuntu Foundations Team Bug Bot (crichton) wrote : | #3 |
tags: | added: patch |
V字龍(Vdragon) (vdragon) wrote : | #4 |
@fourdollars
The xenial debdiff seems to be tainted by color codes...?
Shih-Yuan Lee (fourdollars) wrote : | #5 |
Changed in network-manager (Ubuntu): | |
importance: | Undecided → High |
Changed in oem-priority: | |
importance: | Undecided → Critical |
Sebastien Bacher (seb128) wrote : | #6 |
Thanks Shih-Yuan, could you upstream your change so it's reviewed by somebody who knows the codebase?
Shih-Yuan Lee (fourdollars) wrote : | #7 |
@seb128, the bug is from Ubuntu own patch so the fix can not be upstreamed.
Michael Terry (mterry) wrote : | #8 |
Shih-Yuan, I think it would make more sense to just modify wifi-Signal-
But I've asked cyphermox to check what's happening here, since it seems odd that his change to src/supplicant-
Mathieu Trudel-Lapierre (cyphermox) wrote : | #9 |
That seems wrong. This change was done because you might otherwise get stray SCAN_DONE signals when the scan is in progress -- we should still be getting a SCAN_DONE signal later from the supplicant when we get the scan results. The issue here is that the scan may not be done correctly on return from suspend, but I doubt that forcing a SCAN_DONE to look at the scan results again is the right way to go about fixing this.
Since the issue can be resolved by asking the driver to scan again (via wpa or via iw dev wlan0 scan) and only seems to apply for iwlwifi (as far as I've heard), it would probably really point to either a driver or a wpasupplicant bug.
Tony, what are your thoughts on this? I know you recently spent a lot of time looking at the scanning/scan results logic?
Dave Chiluk (chiluk) wrote : | #10 |
This really should have been worked via one of the myriad of other older open bugs related to this, like 1576747. I'll start duping against this bug.
Launchpad Janitor (janitor) wrote : | #11 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in network-manager (Ubuntu): | |
status: | New → Confirmed |
Dave Chiluk (chiluk) wrote : | #12 |
The above patches do not resolve this issue for my machine. de-duping 1576747.
Shih-Yuan Lee (fourdollars) wrote : | #13 |
- network-manager_1.2.2-0ubuntu4.debdiff Edit (2.3 KiB, text/plain)
Hi Mathieu,
I found this issue on ath9k.
04:00.0 Network controller [0280]: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter [168c:0036] (rev 01)
Subsystem: Dell QCA9565 / AR9565 Wireless Network Adapter [1028:020e]
This patch is just back to the original implementation of the upstream.
Removing wifi-Signal-
BTW, I can also reproduce this issue on my own USB WiFi adapter.
Bus 003 Device 003: ID 07b8:3072 AboCom Systems Inc 802.11n/b/g Mini Wireless LAN USB2.0 Adapter
Driver=rt2800usb (Ralink RT2800 USB Wireless LAN driver.)
Shih-Yuan Lee (fourdollars) wrote : | #14 |
Shih-Yuan Lee (fourdollars) wrote : | #15 |
I can also reproduce the same issue on my own Lenovo ThinkPad X200.
03:00.0 Ethernet controller [0200]: Qualcomm Atheros AR242x / AR542x Wireless Network Adapter (PCI-Express) [168c:001c] (rev 01)
Subsystem: Qualcomm Atheros AR242x / AR542x Wireless Network Adapter (PCI-Express) [168c:0035]
...
Kernel driver in use: ath5k
Kernel modules: ath5k
description: | updated |
Hans Deragon (deragon) wrote : | #16 |
Looks like Bug #1448555 is a duplicate of this one.
Hans Deragon (deragon) wrote : | #17 |
Bug #1380480 is not the same, but until someone finds the proper fix for both issues, why not introduce a script under /etc/pm/sleep.d that restarts the network manager upon resume? Lets get something working for the non technical people / consumer quickly. Such a script would "solve" the problem for both issues.
summary: |
- WiFi malfunction after suspend & resume stress + WiFi malfunction after suspend & resume stress - sudo wpa_cli scan + required to fix it. |
auspex (auspex) wrote : | #18 |
because restarting network-manager from sleep.d isn't even a workaround, let alone a fix. With that, my network successfully reconnects just about as often as if there is nothing in sleep.d.
Which, apparently, would be because /etc/pm/sleep.d is never invoked.
Cristiano Gavião (cvgaviao) wrote : | #19 |
Don't know about others but my Dell's notebook is not only loosing the wifi, after sleep it is not waking up anymore.I need to power off it...
In the log I think I just see these: /lib/systemd/
auspex (auspex) wrote : | #20 |
I finally worked around my problem by adding a script in /lib/systemd/
$ cat /lib/systemd/
#!/bin/bash
case $1 in
"post")
# disable/enable wifi
rfkill block wifi; rfkill unblock wifi
logger "reenabled wifi"
;;
esac
Samuel W (poshul) wrote : | #21 |
I can confirm that this also happens when toggling the radio killswitch on my x230 with Xenial:
Jul 26 09:48:19 Host NetworkManager[
Jul 26 09:48:19 Host kernel: [71025.599893] IPv6: ADDRCONF(
Jul 26 09:48:19 Host wpa_supplicant[
Jul 26 09:48:19 Host wpa_supplicant[
Jul 26 09:48:19 Host NetworkManager[
Jul 26 09:48:19 Host NetworkManager[
Jul 26 09:48:19 Host kernel: [71025.639368] IPv6: ADDRCONF(
Hans Deragon (deragon) wrote : | #22 |
Bug# 1455097 "/etc/pm/sleep.d/ is no more processed" confirms that any solution involving "/etc/pm/sleep.d/" will not work since systemd took over. auspex solution works (thank you), although in my case, I simply restart the Network Manager (systemctl restart network-manager) to be really sure that Wifi will come up (see below).
That said, this bug is a shame to Ubuntu. Any consumer expects wifi/networking to come up upon resume. It is basic. Nobody at Canonical suffers from this problem?
If it is too hard to find a solution at the heart of the problem in a timely matter, we should quickly make a patch to force a rescan or restart the Network Manager. Who on this bug list is entitled to take a decision and package a script under '/lib/systemd/
Following is the reason why I prefer a restart of the Network Manager. There were times that the Network Manager (at least in 14.04 for sure, 16.04, not so sure) would not even come out from sleep. This is why I prefer to restart it upon resume; it fixes multiple problems such as coming out of sleep and Wifi scanning. It does not cost much and I do not find any downsides, except for the nm-applet disappearing and reappearing quickly upon resume.
teo1978 (teo8976) wrote : | #23 |
> Nobody at Canonical suffers from this problem?
LOL I don't think anybody at Canonical actually uses it, otherwise it couldn't possibly be as broken as it is.
Aleve Sicofante (sicofante) wrote : | #24 |
@auspex: Your script doesn't work here. I just created it and gave it execution permissions, rebooted and tried a sleep/resume cycle. No dice.
I'm just amazed no one from Canonical is chiming in. This has been happening from the very moment I installed 16.04 on its release day and it happens in the two laptops I use (Lenovo T400 and Dell Studio 1537, both with Intel wireless cards). It's so obvious I didn't even try to file a bug understanding it would be naturally solved by 16.04.1 at the latest... I'm truly amazed in the worst sense.
monte (monte3) wrote : | #25 |
yeah, canonical, is anyone there?!
Shih-Yuan Lee (fourdollars) wrote : | #26 |
Shih-Yuan Lee (fourdollars) wrote : | #27 |
Shih-Yuan Lee (fourdollars) wrote : | #28 |
Hi,
I made a testing PPA at ppa:fourdollars
Please help to check if it can fix this issue for you.
If not, your problem may not be related to this issue.
Aron Xu (happyaron) wrote : | #29 |
btw, n-m/1.2.2 is in queue for Xenial SRU, fix for this issue can be integrated once it's in -proposed.
auspex (auspex) wrote : Re: [Bug 1585863] Re: WiFi malfunction after suspend & resume stress - sudo wpa_cli scan required to fix it. | #30 |
You can try having the script do "modprobe -r" and "modprobe" on your wifi
module. That should always work, but seemed like overkill in my case. In
any case, these are workarounds, not fixes.
On 4 Aug 2016 6:01 a.m., "Aleve Sicofante" <email address hidden> wrote:
> @auspex: Your script doesn't work here. I just created it and gave it
> execution permissions, rebooted and tried a sleep/resume cycle. No dice.
>
> I'm just amazed no one from Canonical is chiming in. This has been
> happening from the very moment I installed 16.04 on its release day and
> it happens in the two laptops I use (Lenovo T400 and Dell Studio 1537,
> both with Intel wireless cards). It's so obvious I didn't even try to
> file a bug understanding it would be naturally solved by 16.04.1 at the
> latest... I'm truly amazed in the worst sense.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1448555).
> https:/
>
> Title:
> WiFi malfunction after suspend & resume stress - sudo wpa_cli scan
> required to fix it.
>
> To manage notifications about this bug go to:
> https:/
>
Shih-Yuan Lee (fourdollars) wrote : | #31 |
Hi Aron,
I saw n-m/1.2.2 at https:/
When do you expect it will be accepted?
Aron Xu (happyaron) wrote : | #32 |
@fourdollars, I've pinged release team for twice but without response, personally it's nice to be accepted asap.
Mario Olmedo (molmedo1) wrote : | #33 |
same issue here on two laptops. This workaround seems to work for me until I get a real fix.
http://
-Mario
JaSauders (jasauders) wrote : | #34 |
I noticed that NM 1.2.2 hit proposed yesterday. I pulled down proposed but did not see a change with NM 1.2.2 (i.e. I was still seeing the issue), though after re-reading Aron's message, it sounds like the fix is not 1.2.2, but the fix can be applied to 1.2.2 once it becomes available. Anyway, after this I added the testing PPA fourdollars provided to my main laptop (1 of 5 wireless devices I have that are seeing this issue). I've had it running for the last day or so. As of now I have not seen the issue come up after adding the PPA. Whatever was changed in the PPA (which I can't lie, I'm rather curious to know) seems to have done the trick.
While I could instigate the wireless issue before by closing/opening my laptop lid only a few times (this issue was a quite simple roll of the dice, not difficult to notice, further confusing me as to why it wasn't tackled before release but that's another conversation), the real culprit that seemed to always cause it was when my laptop was suspended for several hours. Even after an all-night suspend, the laptop resumed from suspend without issue and connected to wifi this morning.
Thank you folks for the testing PPA. Fingers crossed this issue can be fixed soon!
Shih-Yuan Lee (fourdollars) wrote : | #35 |
- network-manager_1.2.2-0ubuntu0.16.04.2.debdiff Edit (4.5 KiB, text/plain)
This is for 1.2.2 of xenial.
XiaoLe.S (e89021) wrote : | #36 |
XiaoLe.S (e89021) wrote : | #37 |
#36 is for 1.2.2 of yakkety!!
Joakim Koed (vooze) wrote : | #38 |
Thank you for the patches, glad there is some progress, since this https:/
I have just downloaded the network-manager packages from proposed and build with fourdollars's xenial patch.
First two tries with a full reboot, it was showing up as a wifi connection (no ethernet logo) but still no wifi networks in the nm-applet list. Third try it was again showing up as a ethernet logo. So It does not seem to be working.
So no luck. Feel free to ask me to test more patches, I can build myself etc.
Aleve Sicofante (sicofante) wrote : | #39 |
I installed Fourdollars' PPA but I can see current version is higher than that (1.2.4 vs 1.2.2 in the PPA).
I'm using yakkety right now.
How can I test the PPA's version?
tags: | added: suspend-resume |
Hans Deragon (deragon) wrote : | #40 |
- Workaround that restarts the NetworkManager upon resume. Edit (723 bytes, text/x-sh)
This serious issue is dragging to long. People want computers that "just work". If pinpointing the source of the problem is difficult and few resources are available, why not package a workaround that restarts NetworkManager upon resume?
Attached is my workaround. Works nicely. Finally, I have a computer that "just works" and it's not a Mac (well, I have other issues but this one is solved).
Simple move the script under /lib/systemd/
auspex (auspex) wrote : | #41 |
We used to have this. I'm sure, a decade ago, I could actually tell
whatever was managing the hibernate/suspend, in the gui, to remove certain
kernel modules on suspend and load them on resume. Now we're right back to
needing it.
derek
On Thu, Nov 17, 2016 at 1:59 PM, Hans Deragon <email address hidden> wrote:
> This serious issue is dragging to long. People want computers that
> "just work". If pinpointing the source of the problem is difficult and
> few resources are available, why not package a workaround that restarts
> NetworkManager upon resume?
>
> Attached is my workaround. Works nicely. Finally, I have a computer
> that "just works" and it's not a Mac (well, I have other issues but this
> one is solved).
>
> Simple move the script under /lib/systemd/
> executable.
>
> ** Attachment added: "Workaround that restarts the NetworkManager upon
> resume."
> https:/
> manager/
> NetworkManagerR
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1448555).
> https:/
>
> Title:
> WiFi malfunction after suspend & resume stress - sudo wpa_cli scan
> required to fix it.
>
> To manage notifications about this bug go to:
> https:/
>
auspex (auspex) wrote : | #42 |
btw, merely restarting Network Manager never worked for me. I have to
remove iwlwifi and reload it.
derek
On Thu, Nov 17, 2016 at 2:18 PM, Derek Broughton <email address hidden>
wrote:
> We used to have this. I'm sure, a decade ago, I could actually tell
> whatever was managing the hibernate/suspend, in the gui, to remove certain
> kernel modules on suspend and load them on resume. Now we're right back to
> needing it.
>
> derek
>
> On Thu, Nov 17, 2016 at 1:59 PM, Hans Deragon <email address hidden> wrote:
>
>> This serious issue is dragging to long. People want computers that
>> "just work". If pinpointing the source of the problem is difficult and
>> few resources are available, why not package a workaround that restarts
>> NetworkManager upon resume?
>>
>> Attached is my workaround. Works nicely. Finally, I have a computer
>> that "just works" and it's not a Mac (well, I have other issues but this
>> one is solved).
>>
>> Simple move the script under /lib/systemd/
>> executable.
>>
>> ** Attachment added: "Workaround that restarts the NetworkManager upon
>> resume."
>> https:/
>> bug/1585863/
>> estartWorkaroun
>>
>> --
>> You received this bug notification because you are subscribed to a
>> duplicate bug report (1448555).
>> https:/
>>
>> Title:
>> WiFi malfunction after suspend & resume stress - sudo wpa_cli scan
>> required to fix it.
>>
>> To manage notifications about this bug go to:
>> https:/
>>
>
>
Hans Deragon (deragon) wrote : | #43 |
And coming back to my workaround script NetworkManagerR
JaSauders (jasauders) wrote : | #44 |
I'm surprised this is still a thing. I added the common systemd "restart network-manager on resume" script most folks with this issue have used. I added it quite a while ago. My system has been working consistently since then without issue... to the point I actually forgot that this bug existed.
I understand the burning desire to fix the problem at hand, but months (soon to be a year) later, this issue still exists. I don't see the trade-off/
Sorry - I just don't see the point of this bug trailing on longer and longer while users unaware of the "restart network-manager on resume" fix continue to deal with the headache, while on the other hand, had that work-around been issued, folks wouldn't be as angry about this issue as they clearly are.
monte (monte3) wrote : | #45 |
@jasauders
Problem is that bug is present not only for suspend/resume scenario, but also for wifi on/off. And for me it even drop connection sometimes and can't reconnect without wifi restart. It's a problem with wifi drivers and devs not seems to care about it.
Hans Deragon (deragon) wrote : | #46 |
@monte, I get the impression that you may suffer from more than one bug. I have none of the symptoms you describe. I believe that this bug report must remain focused on the resume issue. Any other issue should be in another bug report (maybe already existing?).
In a sideline, sometimes I feel that the wifi scanning stopped or the pause between scans are too long; takes forever for wifi hotspots to show up. But again, that is another issue and we should not further discuss this here.
auspex (auspex) wrote : | #47 |
@JaSauders I think the downside is that restarting NetworkManager, on a system that doesn't have any problem with network connections after a suspend event (and that surely must be most systems, or this would be fixed already) will result in a much slower reconnection to the network.
Phill (phill.l) wrote : | #48 |
@auspex In my experience the physical act of bringing a computer out of suspend takes longer than network manager takes to restart and reconnect (well under 0.5 seconds). It's not only negligible, but I think it's inevitable that there will be some latency in reconnecting after suspend.
I have to agree with other comments supporting the restart workaround. However, it's clear this issue is not going to see any action. Does anyone know of a Debian that's not affected?
monte (monte3) wrote : | #49 |
@deragon Yes, you are right, there is related bug, see bug #1589401. But I'm pretty sure this have one origin and it is wifi driver, especially for intel cards. If you look at the bottom of the discussion on the mentioned bug, you'll find that problem remains even after change to another network manager, so it is deeper than it may look.
no longer affects: | network-manager |
auspex (auspex) wrote : | #50 |
You're kidding? "no longer affects: network-manager"
It certainly did as recently as yesterday!
Wojtek Kazimierczak (w-kazimierczak) wrote : | #51 |
After an upgrade of network-manager to 1.2.4 (SRU bug #1645698) the problem with wifi after suspend/resume on my Lenovo X220 now happens every time, while previously it was less frequent. Perhaps this will help to do something about this problem.
Tanner Blomster (blomstertj) wrote : | #52 |
I am having this problem now as well. A while back I used a script to restart network manager service after resume and this fixed all issues. Yesterday I tried to see if this issue has been fixed or not. After disabling the service with systemd I tested it with a two hour or so suspend. After waking up the computer was still connected to the AP and I was able to browse the web but the network manager icon was the Ethernet one and it didn't list any APs nearby to connect to. I disconnected manually and was unable to connect to an AP since none were listed. I re-enabled the script with systemd and all is working again. So from my end it seems the connection is still going but network manager UI is not working like it should.
tags: | added: papercuts2017 |
MaTachi (matachi) wrote : | #53 |
This bug seems to affect a lot of people on Ask Ubuntu too: "Wifi doesn't work after suspend after 16.04 upgrade" http://
I have a Thinkpad T440 where I previously ran Fedora for multiple releases. Never had any issues with the wifi in combination with sleep/resume. The other day I installed Ubuntu 16.04.1 and ran an update.
The workaround on Ask Ubuntu that is to run `sudo systemctl restart network-
Christian Sarrasin (sxc731) wrote : | #54 |
Fresh 16.04.1 install on ThinkPad X1 carbon 3 with stock Intel 7265 (802.11abgn) WiFi here; laptop also has a Sierra Wireless EM7345 4G LTE WWAN integrate USB module.
Typical scenario: I use the WWAN when out and about, suspend the laptop, come back to office and expect the laptop to re-connect to WiFi. Typically the WWAN reconnects but the network mgr applet shows a stale list of WiFi access points (looks like they're from when I last suspended the laptop). Kern.log has below notices after resume from sleep regarding the WLAN adapter [1]
I tried the following (several times in a row) from the above suggestions to restore my connection (in assumed descending order of "invasion"):
1. sudo wpa_cli scan
2. sudo rfkill block wifi; sleep 3; rfkill unblock wifi
3. sudo systemctl restart network-
#3 did it this time but there was definitely a previous occurrence where it didn't help and only a reboot did.
Just in case this helps shed some light on this lengthy thread. Would agree that this isn't Ubuntu's finest hour; sorry I cannot be more constructive.
[1] ken.log
Jan 6 10:31:49 cinamon5u NetworkManager[
Jan 6 10:31:49 cinamon5u kernel: [ 3239.333883] IPv6: ADDRCONF(
Jan 6 10:31:49 cinamon5u kernel: [ 3239.432191] IPv6: ADDRCONF(
Jan 6 10:31:49 cinamon5u NetworkManager[
Jan 6 10:31:49 cinamon5u NetworkManager[
Jan 6 10:31:49 cinamon5u kernel: [ 3239.721341] IPv6: ADDRCONF(
Jan 6 10:33:19 cinamon5u NetworkManager[
Jan 6 10:33:23 cinamon5u kernel: [ 3333.131109] IPv6: ADDRCONF(
Jan 6 10:33:23 cinamon5u NetworkManager[
Jan 6 10:33:23 cinamon5u NetworkManager[
Jan 6 10:33:23 cinamon5u kernel: [ 3333.175963] IPv6: ADDRCONF(
taiebot65 (dedreuil) wrote : | #55 |
Just updated to NetworkManager version 1.2.6 on Yakkety and confirm that the bug is still present
Éric Piel (pieleric) wrote : | #56 |
Same as comment #52 and #53, while it used to be just once in a while, since a few weeks, it's now _every_ single time that my laptop resumes.
There are many similar bugs but with probably different causes. So to be clear here is the symptoms I see much more recently since a few weeks (on 16.04): after resume, only a couple of wifi networks will be listed at most, and never the one I use.
This workaround does work (to get nm-applet list all the networks again):
sudo service network-manager restart
These things do _not_ work:
* restarting nm-applet
* disabling/enabling the wifi from the hardware key
* trying to unblock the wifi in software (via rfkill), it's not even marked as disabled anyway.
Éric Piel (pieleric) wrote : | #57 |
One more thing: contrarily to the title of this bug report, here "sudo wpa_cli scan" doesn't help to get the list of network again. However, "sudo wpa_cli resume" works.
Éric Piel (pieleric) wrote : | #58 |
As a side-note, as it seems it's been triggered for my laptop by the update to network-manger 1.2.4, one of the few fixes included in 1.2.6 is the following:
* Fixed a bug that caused devices to stay unmanaged after resume from sleep.
So quite probably, updating network-manager to the latest stable version will help....
Éric Piel (pieleric) wrote : | #59 |
Interestingly, this "wpa_cli resume" command is precisely what does /lib/systemd/
I've checked, this script is run at resume, as expected. However, it seems wpa is called too early, and it doesn't have any effect.
Hans Deragon (deragon) wrote : | #60 |
Éric Piel, add a sleep in that file and tell us if it fixes the problem for you.
Something like:
post) $(sleep 10;/sbin/wpa_cli resume) & ;;
Axel Siebenwirth (asiebenwirth) wrote : | #61 |
- Syslog from before and after sleep Edit (26.4 KiB, text/plain)
So, this has been going on for quite a while and still hasn't been fixed?
I've got an DELL E5450 with an Intel Corporation Wireless 7265 wifi adapter.
After resume from sleep wifi network does not reconnect nor does my wireless network show up in the NM gui. But one other strangely enough does and it's always a different one.
See attached log and screenshot.
Is there any proposed official workaround at least?
Vaclav Rehak (vaclav-n) wrote : | #62 |
I can confirm that after every resume my wifi is not working. I used to "solve" it by network-manager restart but running "wpa_cli resume" manually fixes the problem as well.
I tried the sleep workaround by Hans but it did not help. I can see this in /var/log/syslog:
Jan 19 00:20:34 vaclav-ntb systemd[1]: Reached target Sleep.
Jan 19 00:20:34 vaclav-ntb systemd[1]: Starting Suspend...
Jan 19 00:20:34 vaclav-ntb systemd-
Jan 19 00:20:34 vaclav-ntb systemd-
Jan 19 00:20:34 vaclav-ntb systemd-
[snip]
Jan 19 00:20:57 vaclav-ntb NetworkManager[
Jan 19 00:20:57 vaclav-ntb NetworkManager[
...
Jan 19 00:20:57 vaclav-ntb NetworkManager[
Jan 19 00:20:57 vaclav-ntb wpa_supplicant[
Jan 19 00:20:57 vaclav-ntb wpa_supplicant[
Jan 19 00:20:57 vaclav-ntb NetworkManager[
Jan 19 00:20:57 vaclav-ntb NetworkManager[
Jan 19 00:20:57 vaclav-ntb kernel: [138425.339676] IPv6: ADDRCONF(
Matthias (matthi) wrote : | #63 |
Hans Deragon, your suggestion in #60 fixes the issue for me, even if I use sleep 5.
Thinkpad T420 with Intel Corporation Centrino Ultimate-N 6300 (iwlwifi driver)
Christian Sarrasin (sxc731) wrote : | #64 |
Also further to #60, I have put the following in mine (Thinkpad X1 Carbon 3) and it does indeed seem to fix the problem so far - been testing over a few days:
/lib/systemd/
post) (sleep 3 ; /sbin/wpa_cli resume) & ;;
16.04.1 fresh install, kernel 4.4.0-59; network-manager 1.2.2-0ubuntu0.
Anything shorter than 3 seconds seems to be too fast for that race condition; could this suggest this might be better fixed with a systemd dependency?
cascagrossa (cascagrossa-cascao) wrote : | #65 |
Still considering the suggestion of Hans Deragon (# 60), I am testing with:
post) (sleep 1;/sbin/wpa_cli resume) & ;;
A reasonable number of suspend/resume cycles will be needed to make sure it works, maybe a day or two of testing.
Dell Inspiron 5557
Kubuntu 16.04.1 fresh install
kernel 4.4.0-59
Network-manager 1.2.2-0ubuntu0.
Christian Sarrasin (sxc731) wrote : | #66 |
Hi @cascagrossa, just to clarify: my impression is that in order to trigger the bug you'll need to suspend somewhere where the WLAN network you want to connect to at resume time isn't available as it's the scan aspect of things that appears to be inhibited. This is evidenced by the fact that he network-mgr UI shows a stale list of WiFi networks when the bug manifests itself; I've don't *think* I've ever had this bug affect me in a stationary suspend/resume scenario.
cascagrossa (cascagrossa-cascao) wrote : | #67 |
Christian,the failure occurs to me even in a stationary scenario, it does not occur at all suspend/resume cycles, but randomly. (I could not establish a pattern anyway)
In fact, what you described never occured to me, the network-manager UI doesn't show a stale list of wifi networks. In my case the list of access points appears empty and thus cannot connect to any.
Running the wpa_cli scan command, or wpa_cli resume, or restarting the networkmanager, makes the access points reappear and the connection is instantaneous with the preferred network.
taiebot65 (dedreuil) wrote : | #68 |
I tried comment #60 and it does not work for me. My file looks like that but after a restart i am still unable to connect.
My file looks like that now
#!/bin/sh
set -e
if [ "$2" = "suspend" ] || [ "$2" = "hybrid-sleep" ]; then
case "$1" in
pre) /sbin/wpa_cli suspend ;;
post) $(sleep 10;/sbin/wpa_cli resume) & ;;
esac
fi
taiebot65 (dedreuil) wrote : | #69 |
BTW my bug seems to be different I seem to reconnect to the AP but i have no internet connection so i still need to run sudo systemctl restart network-
Éric Piel (pieleric) wrote : | #70 |
@deragon, here, the "$(sleep 10;/sbin/wpa_cli resume)&" doesn't work. Somehow, I wonder if there is some black magic due to systemd, but it doesn't seem that any command after the sleep is ever executed.
Tony Espy (awe) wrote : | #71 |
I've reproduced this on a Thinkpad 410s running 16.04 LTS. The version of network-manager I used is the latest from xenial-updates: 1.2.2-0ubuntu0.
A few comments:
1) The fwts s3 test uses a low-level API to exercise suspend/resume. I've been working with the fwts maintainer on an extension to fwts that allows it to call out to a hook script on each iteration. This makes it possible to ensure that scanning is active for each iteration.
2) I've done some preliminary testing of the version of NM in xenial-proposed (1.2.4-
3) We're pretty sure we know which patch [1] caused the issue, and are working to determine the best way to fix it. The fix provided in comment #5 appears to resolve it, but unfortunately it breaks the original patch's behavior.
@taiebot65
It sounds like you're hitting a different problem, so it'd probably be best if you filed a new bug.
[1] wifi-Signal-
taiebot65 (dedreuil) wrote : | #72 |
@Tony
i have opened #1659059 for my problem
taiebot65 (dedreuil) wrote : | #73 |
Sorry #1659058
Tony Espy (awe) wrote : | #74 |
@taiebot65
Thanks. I'll take a look.
Regarding this bug, it turns out that when I was testing my version of NM with the dropped 'ScanDone' patch (wifi-Signal-
This new version of NM hasn't yet been SRU'd for xenial, as version 1.2.4-0ubuntu0.
Note, I've managed to run 200 cycles of S3 on my Thinkpad without hitting the bug. This included about 25 cycles of manual suspend/resume, and 175 iterations using fwts.
Tony Espy (awe) wrote : | #75 |
Ugh, and then I wake my Thinkpad 410s just now, and I hit the bug on the 201st cycle. ;(-
Guess I'll go back to dropping the patch again from 1.2.6 and see how many cycles I can run on it.
cascagrossa (cascagrossa-cascao) wrote : | #76 |
Just to confirm, about #60 and #65, the workaround does not work.
I also confirm that the script "/lib/systemd/
Marco Pedrazzi (pedrazzi2009) wrote : | #77 |
I confirm, sometime suspend fails and syslog says:
(my ubuntu is an upgrade from 15.10 to 16.04) model: asus-n551vw
Jan 29 19:46:39 asus-n551v systemd[1]: Reached target Sleep.
Jan 29 19:46:39 asus-n551v systemd[1]: Starting Suspend...
Jan 29 19:46:39 asus-n551v systemd-
Jan 29 19:46:39 asus-n551v systemd-
Jan 29 19:46:39 asus-n551v systemd-
and next the pc restart!!
Jan 29 20:39:14 asus-n551v kernel: [ 0.000000] Linux version 4.9.4-040904-
I tryed more version of kernel like: 4.7.3/4.
Dan Dascalescu (ddascalescu+launchpad) wrote : | #78 |
"after resume, only a couple of wifi networks will be listed at most, and never the one I use" - that's exactly the symptom I see after resuming my DELL E7450. Also, the Wi-Fi icon is replaced with an "arrow up arrow down" one. `sudo service network-manager restart` reconnects most of the time, but sometimes that wrong icons stays on.
I've just modified `/lib/systemd/
Kevin Brubeck Unhammer (unhammer) wrote : | #79 |
#64 wrote "could this suggest this might be better fixed with a systemd dependency?", well, http://
Note that scripts or binaries dropped in
should be considered hacks. If applications want to be notified of
system suspend/hibernation and resume, there are much nicer
interfaces available.
(I can't find from that man-page what those interfaces are though.)
Tony Espy (awe) wrote : | #80 |
@Kevin
NetworkManager already has code to monitor system signals related to suspend/resume, so no adding additional scripts to /usr/lib/
@Dan
Different bug... this bug is caused by NetworkManager's WiFi scanning logic stalling due to a race condition. You can tell this by running 'sudo wpa_cli' and watching for scan events. If you don't see any, then you've hit the bug.
I've also unfortunately confirmed that dropping the original patch from 1.2.6 doesn't fix the problem either. I tried a cycle of 100 with my version of 1.2.6 with the original ScanDone patch dropped and I still tripped the bug.
auspex (auspex) wrote : | #81 |
Seems to me that if NM stalls due to a race condition, then restarting NM
*is* a workaround, so yes, adding additional scripts to systemd is a
solution, but not the "answer".
derek
On Fri, Feb 3, 2017 at 1:11 AM, Tony Espy <email address hidden>
wrote:
> @Kevin
>
> NetworkManager already has code to monitor system signals related to
> suspend/resume, so no adding additional scripts to /usr/lib/systemd
> /system-sleep isn't the answer.
>
> @Dan
>
> Different bug... this bug is caused by NetworkManager's WiFi scanning
> logic stalling due to a race condition. You can tell this by running
> 'sudo wpa_cli' and watching for scan events. If you don't see any, then
> you've hit the bug.
>
> I've also unfortunately confirmed that dropping the original patch from
> 1.2.6 doesn't fix the problem either. I tried a cycle of 100 with my
> version of 1.2.6 with the original ScanDone patch dropped and I still
> tripped the bug.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1448555).
> https:/
>
> Title:
> WiFi malfunction after suspend & resume stress - sudo wpa_cli scan
> required to fix it.
>
> To manage notifications about this bug go to:
> https:/
>
description: | updated |
Changed in oem-priority: | |
status: | New → Confirmed |
Changed in oem-priority: | |
assignee: | nobody → Shih-Yuan Lee (fourdollars) |
tags: | added: somerville |
tags: | removed: somerville |
Changed in oem-priority: | |
assignee: | Shih-Yuan Lee (fourdollars) → nobody |
Changed in oem-priority: | |
status: | Confirmed → Triaged |
Shih-Yuan Lee (fourdollars) wrote : | #82 |
I can not reduplicate this issue on Ubuntu 17.04
It looks like that network-manager 1.4.4 has fixed this issue.
Hans Deragon (deragon) wrote : | #83 |
If network-manager 1.4.4 has fixed this issue, it then needs to be backported to 16.04 LTS and 14.04 LTS.
Shih-Yuan Lee (fourdollars) wrote : | #84 |
- network-manager_1.2.4-0ubuntu0.16.04.2.debdiff Edit (12.0 KiB, text/plain)
This issue has been fixed by the following four commits.
From 1b925c0028cdaaf
From: Tony Espy <email address hidden>
Date: Thu, 16 Jun 2016 15:07:33 -0400
Subject: [PATCH] wifi: clear WiFi requested_scan if suppl exits
It's possible for wpa_supplicant to exit with an
outstanding requested_scan pending. This can lead
to a stall condition where scanning no longer occurs.
https:/
(cherry picked from commit 899d7e5cb1eb3bd
---
From eed8fd2e43d244c
From: Tony Espy <email address hidden>
Date: Thu, 16 Jun 2016 15:07:32 -0400
Subject: [PATCH] wifi: clear WiFi requested_scan if suppl goes INACTIVE
It's possible for wpa_supplicant to transition to INACTIVE
state with an outstanding requested_scan pending. This can
lead to a stall condition where scanning no longer occurs.
[<email address hidden>: added break statement to avoid fall-through]
https:/
---
From 788583d9fd35f9a
From: Thomas Haller <email address hidden>
Date: Wed, 6 Jul 2016 09:30:46 +0200
Subject: [PATCH] wifi: fix missing pending-
<warn> [1467730406.7343] device (wlp3s0): add_pending_action (2): scan already pending
file devices/
Fixes: eed8fd2e43d244c
---
From f270bc34b4e503d
From: Thomas Haller <email address hidden>
Date: Tue, 14 Feb 2017 15:10:36 +0100
Subject: [PATCH] device/wifi: block autoconnect while scanning is in progress
We should only start autoconnecting after the scan is complete.
Otherwise, we might activate a shared connection or pick a
connection based on an incomplete scan list.
https:/
(cherry picked from commit 2ab2254dd7336b9
---
Rik Shaw (rik-shaw) wrote : | #85 |
@fourdollars does this commit get applied to 16.04 proposed and then to backports? I (and I am sure others) would be happy to test this for xenial but I am unclear as to the path the patches follow to get to the main repositories.
Shih-Yuan Lee (fourdollars) wrote : | #86 |
I made a PPA at https:/
You can try it and give some feedback.
Shih-Yuan Lee (fourdollars) wrote : | #87 |
Oops, sorry. The package is built failed.
I need to revise the patch again.
Shih-Yuan Lee (fourdollars) wrote : | #88 |
- network-manager_1.2.4-0ubuntu0.16.04.2.debdiff Edit (16.0 KiB, text/plain)
I missed this commit. It should work now.
From 6eaded9071fbf86
From: Thomas Haller <email address hidden>
Date: Tue, 14 Feb 2017 12:45:38 +0100
Subject: [PATCH] device: add get_autoconnect
It allows derived classes to override the autoconnect-allowed
state.
We already have
- NM_DEVICE_
- NMDevicePrivate
D-Bus by the use, to allow the device to autoconnect.
- NMDevicePrivate
internal decision.
- NM_DEVICE_
subscribe to block autoconnect. Currently that is only used
by NMDeviceOlpcMesh.
These two make up for nm_device_
Add another way to allow derived classes to disable autoconnect
temporarily. This could also be achieved by having the device
subscribe to NM_DEVICE_
a signal slot. But a plain function pointer seems easier.
monte (monte3) wrote : | #89 |
Seems it works for my Lenovo x230t. Thanks for your effort!
Rik Shaw (rik-shaw) wrote : | #90 |
The fix from the fourdollars ppa is also working for me: Lenovo x230.
I ran the stress test before applying the fix and confirmed that wifi was non-functioning after the 30 suspend / wake cycles and needed the "sudo wpa_cli scan" to activate it again.
I then added the ppa and applied the update to network-manager and then rebooted. Then I ran the stress test again and after the 30 suspend / wake cycles wifi was still functioning correctly! This is using Ubuntu 16.04.
Vaclav Rehak (vaclav-n) wrote : | #91 |
For me the problem seems to be fixed with today update to network-manager 1.2.6 in xenial-proposed. So far I did some 5-7 suspend/resume cycles in different locations and everything seems to work.
Shih-Yuan Lee (fourdollars) wrote : | #92 |
I tested network-manager 1.2.6-0ubuntu0.
cascagrossa (cascagrossa-cascao) wrote : | #93 |
Also tested network-manager 1.2.6-0ubuntu0.
Looks like the error is fixed in that version of network-manager.
cascagrossa (cascagrossa-cascao) wrote : | #94 |
Since network-manager 1.2.6-0ubuntu0.
code:
apt show network-manager 2>/dev/null | grep -E 'Version|
Version: 1.2.6-0ubuntu0.
APT-Sources: http://
At least for my configuration Dell Inspiron 15 (5557).
Changed in oem-priority: | |
status: | Triaged → Fix Released |
Łukasz Zemczak (sil2100) wrote : | #95 |
Could anyone make sure that this bug is also fixed for yakkety (the original bug target) and zesty? In that case I suppose we could finally close this bug and remove it from the sponsorship queue.
Changed in network-manager (Ubuntu): | |
status: | Confirmed → Fix Released |
Nikolaj Hansen (barnabasdk) wrote : | #96 |
Confirmed Lenovo T440P
PabloAB (pabloab777) wrote : | #97 |
Also here Ubuntu 16.04, kernel 4.11.3, Asus UX303UB.
Probably related to:
https:/
Changed in oem-priority: | |
status: | Fix Released → Triaged |
status: | Triaged → In Progress |
status: | In Progress → Triaged |
Shih-Yuan Lee (fourdollars) wrote : | #98 |
oem-priority needs to the SRU for xenial.
happyaron has finished the major work on https:/
Please help to finish the remaining SRU process.
Olivier Tilloy (osomon) wrote : | #99 |
While I don't have a xenial machine handy to test the bug and fix, I had a look at the debdiff for the packages in Aron's PPA, for some sanity checks.
The following patches have been added:
# fix for LP: #1585863
shared-
device-
platform-
platform-
platform-
platform-
all-use-
core-add-
The patches (which as far as I can tell are all cherrypicks from upstream commits) don't appear to be applied in chronological order (for instance platform-
Olivier Tilloy (osomon) wrote : | #100 |
@fourdollars: have you observed yourself the bug with 1.2.6-0ubuntu0.
Tony Espy (awe) wrote : | #101 |
This bug was marked FixReleased based on the upload of network-manager 1.2.6-0ubuntu0.
Recently there were two comments (#96 and #97) that claim that the bug still exists. Comment #96 doesn't even list which release, and #97 has very little detail. For this bug, the specific case is that after S3, NM failed to restart scanning. So for someone to confirm they've hit this bug, they need to use 'sudo wpa_cli' to check whether or NM is scanning or not. If NM's scan logic is working, you'll see CTRL-EVENT-
Shih-Yuan Lee (fourdollars) wrote : | #102 |
Sorry. Comment #92 is not a good test.
I only tested it on my own laptop.
I still received some reports from my colleagues that it doesn't really fix the problem after that comment.
Shih-Yuan Lee (fourdollars) wrote : | #103 |
We have tested Aron's patch on many OEM projects. The result is good and it does fx the problem. At least it passed all QA tests.
Tony Espy (awe) wrote : | #104 |
There's no evidence (ie. syslogs, package versions, output of wpa_cli) provided which is a basis for re-opening the bug.
Also, please point us to the *exact* patch that is supposed to fix the problem.
Shih-Yuan Lee (fourdollars) wrote : | #105 |
There are many duplicated bugs.
Including this bug, all point to the race conditions, and Aron's patch set are all about the solutions for those race conditions.
If we want to identify every race conditions and the logs, that will be incredibly tedious workloads.
Imaging that we need to de-duplicate those bugs, categorize those bugs and provided the fixes for each bug.
Tony Espy (awe) wrote : | #106 |
My point is that we shouldn't release these patches as an SRU without being able to reproduce the bugs that the patches claim to fix first. Otherwise we risk introducing additional regressions.
So if we want to consider an SRU for NM with one or more of Aaron's patches, then yes we need to go through each one of his patches, try to re-create the problem, validate that the patch fixes it, and then submit the patch upstream for comment as well. I'll put this bug back on the agenda for next week's network/telephony meeting.
Shih-Yuan Lee (fourdollars) wrote : | #107 |
IIRC, Aron's patches are from the upstream. That means we don't need to submit those patches to the upstream.
Olivier Tilloy (osomon) wrote : | #108 |
Indeed, all the patches in Aaron's set are cherry-picked from upstream.
However I agree with Tony, we lack evidence that version 1.2.6-0ubuntu0.
> I still received some reports from my colleagues that it doesn't
> really fix the problem after that comment.
@fourdollars: Can you get your colleagues to confirm the bug following Tony's instructions in comment #101 ?
Shih-Yuan Lee (fourdollars) wrote : | #109 |
Hi, I will close the request of SRU for oem-priority of this issue and check if we can apply Aron's patches on other network-manager's bugs for SRU.
Changed in oem-priority: | |
status: | Triaged → Fix Released |
Olivier Tilloy (osomon) wrote : | #110 |
For future reference, this is the list of upstream commits corresponding to Aaron's patches, in the order they are being applied:
312cea870dfbc36
shared: add nm_auto_close and nm_auto_fclose
ed299cc8605a829
device/wwan: use nm_auto_close instead of gs_fd_close
713c74f6e4a88f8
platform: add a new function nmp_utils_
e714a20bc2464dc
platform: refactor wifi_utils_
b95556eb781a18e
platform: wifi: use nmp_utils_
76876e896c242fd
platform: refactor nmp_utils_
4bdee37771ae741
all: use O_CLOEXEC for file descriptors
dcc8de16b2acc43
core: add utils for file handling
As far as I can tell, none of them have been backported to the 1.2 branch of NetworkManager.
Kai-Heng Feng (kaihengfeng) wrote : | #111 |
Is it feasible to put NM 1.4 into -backports pocket?
Mark (mago90) wrote : | #112 |
I am on Lubuntu 16.04.03 and I am having trouble with WIFI reconnection after suspending the system. I opened https:/
Has the fix been relseased for 16.04.3? There are various tickets reporting the same issue after suspending...but so far no luck with fixes.
The attachment "network- manager_ 1.2.2-0ubuntu3. debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]