wireless takes several seconds longer to connect from standby

[Mike]

My observation is that network-manager is taking longer to connect to my wireless access point than 11.10.
I trust the rest of the attached info will reveal all necessary system data.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.4.0-0ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-24.38-generic-pae 3.2.16
Uname: Linux 3.2.0-24-generic-pae i686
NonfreeKernelModules: wl nvidia
ApportVersion: 2.0.1-0ubuntu7
Architecture: i386
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Date: Fri May 4 12:47:28 2012
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
IpRoute:
 default via 192.168.1.1 dev eth1 proto static
 169.254.0.0/16 dev eth1 scope link metric 1000
 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.116 metric 2
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-con:
 NAME UUID TYPE TIMESTAMP TIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH
 Wired connection 1 264165e3-74f6-4750-8198-6e8b6d3632cf 802-3-ethernet 1336133356 Fri 04 May 2012 07:09:16 AM CDT yes no /org/freedesktop/NetworkManager/Settings/1
 2.4GHzWPA2 9afe3092-8693-4b03-92cd-fd179af0fca8 802-11-wireless 1336153624 Fri 04 May 2012 12:47:04 PM CDT yes no /org/freedesktop/NetworkManager/Settings/0
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth1 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.4.0 connected enabled enabled enabled enabled enabled

[Launchpad Janitor (janitor)]

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

[Pau Oliva (poliva)]

I have the same issue here, MacBookAir4,2 with a Broadcom BCM43224 802.11a/b/g/n using 'wl' driver.
It takes around 30 seconds to connect to the wireless network after suspend in 12.04, while in 11.10 it was barely 5 or 6 seconds.

[Pau Oliva (poliva)]

I've attached log of network-manager with debug enabled on both 11.10 and 12.04, notice the differences between both logs.

I don't know if it's related, but on ubuntu 12.04 the 'iw' command is broken and complains about missing nl80211.

[Pau Oliva (poliva)]

The issue is not related to nl8021: modprobing 'mac80211' makes 'iw' command work correctly, but the issue with network-manager taking too long to re-connect still exists.

Any help fixing this would be appreciated.

[Pau Oliva (poliva)]

I've been digging into this a bit more, it seems to me the problem is in communication between network-manager and wpa_supplicant. I enabled debugging in wpa-supplicant, see the attached log file.

[Pau Oliva (poliva)]

Finally found the root reason of the problem! :-)

Both wl (broadcom proprietary driver) and brcmsmac (the open source driver) are installed, in 11.10 this wasn't a problem since the brcmsmac was not blacklisted, and even if the wl driver was loaded, it failed silently and brcmsmac was used instead.

In 12.04, the wl driver has been updated to version 5.100.82.38+bdcom-0ubuntu6.1 which includes the following fix:

https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/873117/comments/36

that basically blacklists the brcmsmac module, forcing the wl proprietary driver to be in use.

When the wl driver is in use, resume takes 30 seconds to associate to the network, but when the brcmsmac driver is in use, it just takes 5 seconds.

I just blacklisted the 'wl' module, and happily using the brcmsmac now in 12.04, without any issues. Problem solved!

[Pau Oliva (poliva)]

Attached is a patch which reduces the waiting timeout from 30 seconds to 10 seconds, it is based on this:

http://lists.shmoo.com/pipermail/hostap/2011-February/022564.html

[Pau Oliva (poliva)]

Here's a script that wiill download and patch wpa-supplicant automatically, to fix the timeout when using wl driver:

http://pof.eslack.org/archives/files/mba42/fix-wl.sh

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "fix_wl_timeout.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Pau Oliva (poliva)]

This is a better patch, which fixes the driver_wext in wpasupplicant when using broadcom's wl driver and shouldn't have effect when using any other underlying wifi driver, this is adapted from here to the current version of wpasupplicant in ubuntu:

http://lists.shmoo.com/pipermail/hostap/2011-March/022891.html

With this patch, the time to wait after a suspend when using networkmanager is around 12 seconds, i think it's an acceptable alternative if the patch gets included in ubuntu's wpasupplicant package.

[Launchpad Janitor (janitor)]

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

[Andrea Corbellini (andrea.corbellini)]

Hi Pau, and thank you for your work. Please consider going thorough described in this wiki page in order to have your patch included in Ubuntu: https://wiki.ubuntu.com/Bugs/HowToFix

You may also want to contact upstream directly.

[Pau Oliva (poliva)]

Thanks Andrea, I have gone through the wiki steps and pushed the branch to Launchpad:

https://code.launchpad.net/~poliva/ubuntu/precise/wpasupplicant/fix-for-994739

I have not contacted upstream directly, as the development of wpasupplicant 0.7.3 is stopped (wpasupplicant stable is now 1.0) and a very similar patch to this was not accepted upstream when Kalle Valo (kvalo) submitted it in March 2011.

[Mathieu Trudel-Lapierre (cyphermox)]

Looking good so far; I'll just check back on the mailing list posts and review/sponsor to Precise.

[Mathieu Trudel-Lapierre (cyphermox)]

I can't reproduce that delay on 12.04 with a different system (but also broadcom, using a 4312). I really wish this patch was accepted upstream in some form or another before applying this to Precise, especially since it really should be applicable to wpa 1.0 anyway.

Pau, could you please bring up that patch on the mailing list again so that we can get a clear response on whether or not it's acceptable? I think it's probably in close enough of an acceptable form already.

In the meantime I'm willing to sponsor this to Quantal (since it needs to be done anyway before we should SRU it to Precise). It would be useful if you could test a Quantal LiveCD and confirm whether you also see the same multisecond delay on resume from suspend or on first boot.

[Xu Zhen (xuzhen666)]

Pau, It seems that your patch made my atheros card fail to find the AP.

I upgraded wpasupplicant from 1.0-2ubuntu1 to 1.0-2ubuntu2 today.
after reboot, my card cannot connect to the AP.

I run
sudo /sbin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -dd
to see what happend, and I got these:

...
Scan SSID - hexdump_ascii(len=7):
     XX XX XX XX XX XX XX *******
wlan0: Starting AP scan for specific SSID(s)
Scan requested (ret=0) - scan timeout 10 seconds
EAPOL: disable timer tick
EAPOL: Supplicant port status: Unauthorized
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
WEXT: if_removed already cleared - ignore event
Wireless event: cmd=0x8b19 len=16
wlan0: Event SCAN_RESULTS (3) received
Scan results did not fit - trying larger buffer (8192 bytes)
ioctl[SIOCGIWSCAN]: Argument list too long
wlan0: Failed to get scan results
wlan0: Failed to get scan results - try scanning again
...

after downgrade to 1.0-2ubuntu1, using the same command, I got these:

...
Scan SSID - hexdump_ascii(len=7):
     XX XX XX XX XX XX XX *******
wlan0: Starting AP scan for specific SSID(s)
Scan requested (ret=0) - scan timeout 10 seconds
EAPOL: disable timer tick
EAPOL: Supplicant port status: Unauthorized
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
WEXT: if_removed already cleared - ignore event
Wireless event: cmd=0x8b19 len=16
wlan0: Event SCAN_RESULTS (3) received
Scan results did not fit - trying larger buffer (8192 bytes)
Received 7564 bytes of scan results (14 BSSes)
wlan0: BSS: Start scan result update 1
...

I checked the changelog of wpasupplicant, It showed that the only difference between 1.0-2ubuntu1 and 1.0-2ubuntu2 is fix_driver_wext_for_broadcom_wl.patch

[Andrea Cimitan (cimi)]

My broadcom wifi stopped working with network manager (can't find AP, while iwlist eth1 scan finds them) after the upgrade: downgrading the package works

[Lukas Hejtmanek (xhejtman)]

I can confirm that the patch fix_driver_wext_for_broadcom_wl.patch is broken, supplicant stopped working with iwlwifi driver resulting with:

ioctl[SIOCGIWSCAN]: Argument list too long
ioctl[SIOCGIWSCAN]: Argument list too long
ioctl[SIOCGIWSCAN]: Argument list too long
ioctl[SIOCGIWSCAN]: Argument list too long
ioctl[SIOCGIWSCAN]: Argument list too long
ioctl[SIOCGIWSCAN]: Argument list too long

[Pau Oliva (poliva)]

Mathieu: ¿Can you revert the patch? it's breaking everyone else's wifi, I will think of a different approach to try to workaround the specific issue on BCM4353 with wl driver (maybe it's better to submit a patch to the wl driver itself).

[Andrea Cimitan (cimi)]

It's breaking wifi also on broadcom :-)

[Mathieu Trudel-Lapierre (cyphermox)]

I'm not convinced it's actually what's breaking "everyone's wifi"; specifically, this couldn't possibly be affecting iwlwifi; since it uses nl80211 rather than wext -- the code changes are specific to wext. (And also, because my wifi works just fine).

However, there is sufficient uncertainty with whether it actually fixes anything (and enough reports of issues) that it might as well be reverted.

There's a workaround though -- seems like the wl driver might support nl80211 now, so switching it to use that framework might help a lot (or make the driver behave much worse... will need careful testing).

[Mathieu Trudel-Lapierre (cyphermox)]

broadcom-sta-dkms should already build with cfg80211/nl80211, there shouldn't be a need to patch it to do so -- it's dependent on the kernel version number, which should be higher than 2.6.32 on all the releases we care about anyway....

But the actual test in broadcom-sta is broken for the >3.0 releases. Why would it not be ;)