System takes too long to activate wifi on resume

[Elladan]

Binary package hint: network-manager

Using Maverick on a Dell Mini 10v, Ubuntu takes much, much longer to activate wifi when resuming from sleep.

With Lucid, after opening the lid, NM would start searching for wifi after a few seconds -- perhaps 2-3. It would quickly reconnect and the laptop would be usable.

With Maverick, the system wakes up slightly slower (but not enough to matter). However, the wifi takes dramatically longer to reactivate -- about 30 seconds.

During this time, the red network disabled icon is displayed. Once the icon switches to the pulsing wifi-connecting logo, the connection is re-enabled quickly.

It's acting like NM didn't notice the system just woke up for 30 seconds, basically.

This is very annoying on a laptop -- wifi connection performance is important, and worked well in Lucid.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: network-manager 0.8.1+git.20100810t184654.ab580f4-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic i686
NonfreeKernelModules: wl
Architecture: i386
CRDA: Error: [Errno 2] No such file or directory
Date: Sun Oct 24 09:07:36 2010
IfupdownConfig:
 auto lo
 iface lo inet loopback
IpRoute:
 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.103 metric 2
 169.254.0.0/16 dev eth1 scope link metric 1000
 default via 192.168.1.1 dev eth1 proto static
Keyfiles: Error: [Errno 2] No such file or directory
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: network-manager

[Elladan (elladan)]

I was able to work around this by putting a script to run:

sleep 1
iwlist scan

... after the system comes out of resume (in /etc/pm/sleep.d)

Perhaps this is actually a bug in the wireless driver where it's not re-probing after a power event?

[wch (winston-stdout)]

I have the same issue with my Dell mini 9. It was reasonably fast to connect with 10.04, but much slower with 10.10. There's the same delay before the icon indicates that it's even trying to connect, but once it does, it connects pretty quickly.

I tried running 'sudo iwlist scan' from a terminal immediately after sleep. It seems to help for me as well.

[Elladan (elladan)]

wch: If you put the attached script in /etc/pm/sleep.d/ it should help. It just runs iwlist scan for you on resume.

[wch (winston-stdout)]

I've found that the 'iwlist scan' thing doesn't always make the network connect immediately. If the computer has been asleep for a short time, it works, but if the computer has been asleep for a long time (overnight, for example), then the 'iwlist scan' doesn't seem to help it connect faster.

In the case where it has been asleep for a long time, the scan still shows the available networks in the terminal, but the network manager icon in the task bar doesn't change to the connecting (circle) state. I still have to wait about 30 seconds before it changes to that state. Once it does that, then it's just a few seconds to connect.

When the computer has been asleep for a short time, the iwlist scan makes the icon change to the connecting state immediately, and then it's a few seconds to connect.

[Mathieu Trudel-Lapierre (cyphermox)]

This sounds to me like an issue with the supplicant or directly with the wireless driver, but to be certain, could you guys please do a clean boot, use the computer normally and put it to suspend for the night, then once you resume it attach the contents of /var/log/syslog (and/or syslog.1 or others, if you can find at which point in those files the system boots) to this bug? I don't see any message from NetworkManager in the logs currently attached, though it's clear it was sent after to standby/resume attempts.

With this, and provided NetworkManager then logs the supplicant state changes, it should be pretty clear with that and the message from the kernel what exactly is going on.

@wch: Please also confirm which driver you use -- Justin's report mentions wl, which would show as "STA" in jockey (the restricted drivers configuration panel in System->Administration). If you don't use the same driver, it may be a different issue or an indication that NM is the culprit :)

Thanks!

[Elladan (elladan)]

I've attached various log files, annotated with blocks of ==============================. Hopefully this is enough?

I didn't leave the laptop to sleep overnight, since this reproduces easily every time. I just disabled my special "iwlist scan"
script.

The most interesting logs look like syslog, daemon.log, and perhaps pm-suspend.log.

Thanks.

[Mathieu Trudel-Lapierre (cyphermox)]

My guess is it's an issue on the kernel side, note the error:

Dec 8 22:33:55 paprika wpa_supplicant[993]: Association request to the driver failed

Seems to me like the driver takes some time to return from low-power mode (which it gets set in by pm-utils).

To further pin-point this, try to modify /usr/lib/pm-utils/power.d to disable it, to see if it works similarly to your hack.

[Mathieu Trudel-Lapierre (cyphermox)]

Justin,

Any news about this?

[Elladan (elladan)]

Hi,

I tried adding an exit 0 to /usr/lib/pm-utils/power.d/wireless, as well as disabling it a few other ways. However, this did not
appear to have any affect on wireless resume speed.

[Mathieu Trudel-Lapierre (cyphermox)]

There's a possible patch in wpasupplicant Kalle Valo wrote and submitted on the w1.fi mailing list. Once it gets reviewed we should consider applying it and testing if it also fixes rescanning delays after resume... I get the feeling it might.

For now, setting this bug back to Confirmed is the best we can do.

[Jordon Bedwell (envygeeks)]

Please attach a patch so that I might apply it and test it to report results.

[Elladan (elladan)]

Confirming this still affects 12.04 with the same laptop.

I didn't have my old hack script handy, so I put a new one in /etc/pm/sleep.d with a resume case, that did:

(in bash): for a in {1..10}; do iwlist scan > /dev/null; sleep 1; done

Yeah, this lame hack seems to work perfectly.

[Mathieu Trudel-Lapierre (cyphermox)]

So then this falls into being a symptom of bug 994739; which we'll fix in the development release and then work to get applied as Stable update to 12.04; I'm marking it as a duplicate.