wireless takes several seconds longer to connect from standby
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| broadcom-sta (Ubuntu) |
Medium
|
Unassigned | ||
| Precise |
Medium
|
Unassigned | ||
| network-manager (Ubuntu) |
Undecided
|
Unassigned | ||
| Precise |
Undecided
|
Unassigned | ||
| wpa (Ubuntu) |
Undecided
|
Unassigned | ||
| Precise |
Undecided
|
Unassigned | ||
| wpasupplicant (Ubuntu) |
Medium
|
Unassigned | ||
| Precise |
Medium
|
Unassigned |
Bug Description
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
ProcVersionSign
Uname: Linux 3.2.0-24-
NonfreeKernelMo
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.
[main]
NetworkingEnab
WirelessEnable
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-
2.4GHzWPA2 9afe3092-
nmcli-dev:
DEVICE TYPE STATE DBUS-PATH
eth1 802-11-wireless connected /org/freedeskto
eth0 802-3-ethernet unavailable /org/freedeskto
nmcli-nm:
RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
running 0.9.4.0 connected enabled enabled enabled enabled enabled
Related branches
- Mathieu Trudel-Lapierre: Needs Fixing on 2012-06-28
- Ubuntu branches: Pending requested 2012-05-21
-
Diff: 159 lines (+91/-0)6 files modified.pc/applied-patches (+1/-0)
debian/changelog (+12/-0)
debian/patches/fix_driver_wext_for_broadcom_wl.patch (+62/-0)
debian/patches/series (+1/-0)
src/drivers/driver_wext.c (+14/-0)
src/drivers/driver_wext.h (+1/-0)
Mike (bild85) wrote : | #1 |
Pau Oliva (poliva) wrote : | #3 |
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) wrote : | #4 |
Pau Oliva (poliva) wrote : | #5 |
Pau Oliva (poliva) wrote : | #6 |
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) wrote : | #7 |
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) wrote : | #8 |
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) wrote : | #9 |
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.
https:/
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) wrote : | #10 |
Attached is a patch which reduces the waiting timeout from 30 seconds to 10 seconds, it is based on this:
http://
Pau Oliva (poliva) wrote : | #11 |
Here's a script that wiill download and patch wpa-supplicant automatically, to fix the timeout when using wl driver:
The attachment "fix_wl_
[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.]
tags: | added: patch |
Changed in network-manager (Ubuntu): | |
status: | Confirmed → Invalid |
Pau Oliva (poliva) wrote : | #13 |
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://
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) wrote : | #14 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in wpasupplicant (Ubuntu): | |
status: | New → Confirmed |
affects: | wpasupplicant → wpasupplicant (Ubuntu) |
Changed in wpasupplicant (Ubuntu): | |
status: | New → Confirmed |
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:/
You may also want to contact upstream directly.
Pau Oliva (poliva) wrote : | #16 |
Thanks Andrea, I have gone through the wiki steps and pushed the branch to Launchpad:
https:/
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.
Looking good so far; I'll just check back on the mailing list posts and review/sponsor to Precise.
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.
Changed in wpasupplicant (Ubuntu Precise): | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in wpasupplicant (Ubuntu): | |
importance: | Undecided → Medium |
assignee: | nobody → Mathieu Trudel-Lapierre (mathieu-tl) |
status: | Confirmed → Triaged |
Changed in wpasupplicant (Ubuntu Precise): | |
status: | Confirmed → Triaged |
Changed in wpasupplicant (Ubuntu): | |
status: | Triaged → In Progress |
Changed in network-manager (Ubuntu Precise): | |
status: | New → Invalid |
Xu Zhen (xuzhen666) wrote : | #19 |
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_
to see what happend, and I got these:
...
Scan SSID - hexdump_
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_
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_
Andrea Cimitan (cimi) wrote : | #20 |
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) wrote : | #21 |
I can confirm that the patch fix_driver_
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) wrote : | #22 |
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) wrote : | #23 |
It's breaking wifi also on broadcom :-)
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).
Changed in wpa (Ubuntu Precise): | |
status: | New → Invalid |
Changed in wpasupplicant (Ubuntu): | |
status: | In Progress → Invalid |
assignee: | Mathieu Trudel-Lapierre (mathieu-tl) → nobody |
Changed in wpa (Ubuntu): | |
status: | New → Fix Released |
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 ;)
Changed in broadcom-sta (Ubuntu Precise): | |
status: | New → Triaged |
Changed in broadcom-sta (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in broadcom-sta (Ubuntu Precise): | |
importance: | Undecided → Medium |
Status changed to 'Confirmed' because the bug affects multiple users.