wireless takes several seconds longer to connect from standby

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

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.

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.

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.

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.

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!

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

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

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.]

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.

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

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.

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.

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.

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

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

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

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).

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).

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 ;)

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release