My Dell Inspiron 1501 apparently has the same problem with the STA driver, and I can confirm that the workaround proposed by jejbarr for duplicate bug 732038 works for me. Of course this uses the B43 driver, not the STA driver....

What I did:

· used the additional drivers GUI to deactivate the STA driver;
· sudo apt-get install firmware-b43-installer
· restarted
· I had to use FUNCTION-F2 to turn the wifi on

Bug confirmed, please fix.
---------------------------------
The wl driver does not work with the ssb module loaded since it conflicts with the builtin ssb support in wl.
You'll need to unload the ssb module before loading wl. This requirement has not changed since original release of this driver.

If you read the previous comments carefully you will find this potential workaround. I can't confirm it works but Broadcom reckon it's a common issue:

[from http://www.broadcom.com/docs/linux_sta/README.txt]
* If the wl driver loads but doesn't seem to do anything:
the ssb module may be the cause. Sometimes blacklisting ssb may not
be enough to prevent it from loading and it loads anyway. (This is mostly
seen on Ubuntu/Debian systems).

Check to see if ssb, wl or b43 is loaded:
# lsmod | grep "b43\|ssb\|wl"

I'm pretty sure b43-fwcutter is just to make the b43 module work. This
bug however is about making the wl module work. wl (bcmwl) should
already have built-in firmware because it's a proprietary driver. Though
using b43 (hence removing bcmwl) might be a feasible workaround for some.

Also, isn't the package firmware-b43-installer designed to do the
firmware cutting for you?

Yesterday regular update contained broadcom wifi driver as well (if I saw correctly), but it didn't make any difference. My wifi still doesn't work even though STA driver is activated.

In my experience, on earlier versions of Ubuntu, fwcutter driver gave me a bit weaker signal strength then STA driver, so I would prefer to make STA driver work properly. As I'm on 11.04, I'll wait for final release before I try to do some workaround, hoping some of the updates will fix it.

I encountered the same problem on installing STA driver using Jockey. But I removed it, installed firmware-b43-installer package and did modprobe b43 after which I could bring up the wireless network using ifconfig.

Thanks, Gabriel. It's a much better solution. You can also lock the version it in synaptic, so it doesn't update with the regular updates. I think the driver should be reverted to the old version until this bug is solved.

Has anyone yet tested Broadcom's recommended workaround for this problem? That is forcefully removing and disabling the stubborn ssb module? See previous comments #17, #14.

Also, reverting to 5.60.* might be a great workaround for this particular bug however the newer driver 5.100.* works well on newer Broadcom chips, so simply reverting 5.100 to 5.60 for all users would seem a little heavy handed.

Daniel, I tried what they suggested, but ssb still loads because it required by b44- the driver for the ethernet.
As a workaround I use the b43 driver, which gets a weaker signal but works. I will try to install the previous version of wl (sta) driver as suggested here.

I've noticed ssb causing conflicts in other bugs too. A quick search shows it's not a new issue, but has been causing people grief for several years. The best workaround I have found (untested) is this forcing the load order (in /etc/rc.local):

I know the blacklist file is meant to be removed when the package is removed, but I recently noticed it's not actually removed/upgraded correctly when bcmwl-kernel-source is upgraded. So if you've;
* had some version of that package installed since before 2009-06-19; or
* if you for some reason didn't have b44 loaded when the package was being installed; or
* if you had a lingering blacklist-bcm43.conf for any reason before the package was installed;
then you will be missing the above workaround Alberto introduced in 2009.

I have a BCM43225, which is not supported by b43 firmware, so I had to search for another workaround.
I found that removing acer-wmi module (I've got a acer AspireOne 753) does make wifi working (but, of course, kills the bluetooth module).
To the noobs, the command is: sudo modprobe -r acer-wmi

It's a workaround I can accept, but please keep on searching for a solution.
I'd like ubuntu developers to spend a little more effort on this kind of tests, since my first thought was "damn! My pc is unusable without wifi", and the second was "which other distribution may I try?". Luckily for Ubuntu, I am patient, and Fedora and Suse are likely to undergo bad times soon.

I reinstalled ubuntu 10.10 since wireless and ssh tunneling were not working, and with my laptop I need both (especially ssh tunneling with vnc and unison to remotely work and synch with my office computer). I will keep checking the status of the bugs and install natty when fixes will be released.

I have natty 64 bit in a acer timeline x 1830t notebook, and broadcom wireless works after killing the module acer-wmi.

Matthew, I get that you may be determined to use the maverick drivers for
some reason, but have you just tried the b43 series that are in the oneiric
repositories? They still work fine for me on my Latitude 1501 with 4311
hardware...

Same Issue here on dell latitude d530, with bcm4311. tried all solutions on this bug report, and in this help post https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx but with no success. wifi dont work in any manner, please give some attention, I have 5 identical dell notebooks that I wish ubuntu (preferably) to work so I can get them back to the students here.

Upgraded to Precise Pangolin, and everything broke again: the 5.60 driver does not seem to work anymore, and the 5.100 one doesn't work either (the driver fails with an "error 21", apparently).

After swearing and sweating for a couple of hours, I followed different advice, uninstalled bcmwl-kernel-source and installed b43-fwcutter + firmware-b43-installer (which didn't work in previous versions for me), and everything started working again.

Download previous source of driver version bcmwl-5.60.48.36
In file src/include/wl_linux.h replace #include <linux/autoconf.h> to <generated/autoconf.h>
in file src/wl/sys/wl_linux.c find function wl_set_multicast_list (sting 1416) and replace it all on

Just to add to my previous comment, sometimes the wireless "stops working" - ie I do not seem to have internet connectivity - though ifconfig iwconfig etc look ok. Using Fn-wireless to turn the wifi off and on again restores the connectivity.

The attachment "switch_to.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

With today's iso I no longer had the wireless crash and my wired connection seems to continue working. Therefore I was able to install the legacy drivers and now the laptop is running again in wireless mode.

Adam Porter, this bug did indeed first appear in Natty and up to the last time I installed 13.04 on my Dell Inspiron 1501 with 4311 hardware, was the same problem. The STA drivers selected for the install don't work with the 4311 ie there is no working wireless adapter visible in the system. The same fix has also worked since then, which is uninstalling the STA driver and installing the b43 driver.

I cannot personally vouch for the original workaround proposed which was downgrading the STA version.

I have looked at the comments for the bug you mention, namely 1097519 and there seems to be a lively dispute the "correct" solution for this problem. Also the people involved in that discussion seem to be working with 4313 devices.

Therefore I respectfully suggest that moving this bug to Invalid status is premature or perhaps incorrect.

Chris, I'm not sure I understand what you mean. I only marked it invalid in that one context. If the b43 driver works, then Ubuntu should select that driver. That would make this a dupe of bug 1097519, which states that the wrong driver is used for some chipsets. In one of the comments I made on that bug yesterday, I mentioned that some users have found success using broadcom-sta*, and some by using b43, and others by using brcmsmac.

As I understand it now there are possibly two issues:

1. Ubuntu selecting the wrong driver upon install, as you mentioned. That's covered by bug 1097519.
2. A certain driver (e.g. broadcom-sta) not working with a chipset it claims to support. That would be a separate issue.

So what I'm going to do now is:

1. In the Ubuntu project, mark this as a dupe of bug 1097519, because the working driver needs to be selected by Ubuntu.
2. In the Broadcom 802.11 Linux STA driver project, mark this as incomplete. If I understand you to mean that the broadcom-sta driver doesn't work with some chipsets it claims to, then I guess you should mark this bug as New there.

And then there's the in-tree driver, which for at least some cards makes those packages obsolete, at least on some kernel versions.

It seems to me that it still boils down to Ubuntu needing to install the proper driver. For example, if broadcom-sta_ 5.100.82.112-9 said it supported BCM4313, but BCM4313 worked with the in-tree driver, broadcom-sta shouldn't even be installed, regardless of whether BCM4313 worked with broadcom-sta. Or if a 5.100.82.38 of some package didn't work, but the newer version did, that should be fixed by the newer version.

Now if there are some versions of some driver packages that don't properly work with some cards, that could result in two problems:

1. Users upgrading distro versions with a package could end up with a version of the package that doesn't work anymore (that happened to me). That's still a matter of Ubuntu choosing the correct package.

2. Users trying to manually choose a package, searching package descriptions, and choosing a package that happens to not work with their card. That's unfortunate and frustrating. But the only way to solve this is to comprehensively test all these different versions of all these different packages with all the different cards they claim to support, some of which might have subtle bugs with certain cards, and some of which seem to have regressions in newer versions.

So if you want this bug to be #2...well, ok, I guess I can't argue with that. But I'm not sure it's practical to really solve it. I think the best we can realistically hope for is to get Ubuntu automatically choosing the right package on first install and hopefully on distro upgrade. And probably the only way we can do that is to act on specific reports of specific cards failing with specific versions of specific driver packages.

Maybe the best thing for now would be to make a note in all driver packages that there are multiple driver packages that support the same cards, and if one package doesn't work, the user should try the others (including the in-tree one, which requires uninstalling the driver packages). I think that there are just too many combinations to be proactively comprehensive. With all the versions and packages and claimed-supported cards, there ends up being something like 432 combinations.

I think all of this came about because Broadcom broke support for older cards when they released the 6.20.x drivers. Maybe it was an accident, or maybe they forgot to note that older cards were no longer supported by newer releases. Whatever happened, it sure has made a mess!

Anyway, I feel like I may be more confused now than I was before. I'm going to mark this bug as Incomplete in the Ubuntu project and let y...

What if we think about this from the perspective of the desired outcome - which should be, I guess, a fresh install that just works.

There is no point in continuing to have Ubuntu install STA drivers that don't work wiith 4311 hardware, which is what has happened since natty.

If the right solution is to fix the STA driver (or its configuration or whatever) so that it does work with the 4311, then I say "let's fix it".

If the right solution is to toss the STA driver, or mark it as unsuitable for the 4311, and convince Ubuntu to install b43 (or whatever) then I say "let's install b43 instead".

I don't really know all the ins and outs of the various drivers, so I don't know which is the right solution. I just know that the STA driver in all its incarnations since natty has failed to work with the 4311 as configured and that I fix it by installing b43 instead while I wait for an Ubuntu release that does not have this problem.

If you would like me to test various configurations, my poor old Inspiron is dedicated to that kind of thing so please ask.

For me the b43 installer in the repos does the trick. One must also
manually turn on the wifi with the Fn-key switch.

As pointes out above the version numbers in the title may not be current;
there are also many related bugs (although I disagree which are
duplicates); and the "real problem" appears to be that whatever code
decides which driver to use is jncorrect.

Also, for awhile at least the non-working driver was causing the whole
networking stack to crash though I think that is not the case in 13.10.

For clarity I have an inspiron 1501 with the b43 driver running fine on the
4311 device.