Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 183273 - bcm43xx firmware should be easy to install, or else the hardware should be ignored
Summary: bcm43xx firmware should be easy to install, or else the hardware should be ig...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-02-27 21:09 UTC by Stuart Jansen
Modified: 2007-11-30 22:11 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-11-02 19:20:31 UTC

Attachments (Terms of Use)

Description Stuart Jansen 2006-02-27 21:09:04 UTC
Description of problem:
Having an non-binary broadcom wireless driver is great. But installing the
firmware is a pain. system-config-network shouldn't list hardware that can't be used

Actual results:
system-config-network can see the hardware, but after configuring the device it
can't be activated. I hadn't followed the development of broadcom drivers
closesly (basically because I'd given up home) so it took me awhile to discover
that firmware was needed but not included.

Expected results:
Ideally, the firmware install should be installed automatically. Perhaps using a
solution similar to

Alternatively, the user should be given useful information explaining why the
card won't work until firmware is installed. If neither is possible, unusable
hardware should be ignored by system-config-network.

Comment 1 Bill Nottingham 2006-02-28 17:07:44 UTC
ipw2xxx is in the same boat. Really, we'd have to trap the firmware event
somehow via udev/hal and post errors if there is no firmware available.

Comment 2 John (J5) Palmieri 2006-05-08 17:28:29 UTC
This is not a hal issue.  Ideally the kernel should issue one error and unload
the driver or just have it stop complaining.

If you want a feature in HAL that flags the device as not having firmware I
would ask upstream.

Comment 3 Dave Jones 2006-10-16 18:35:07 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 4 Christopher Beland 2007-03-03 04:15:21 UTC
The same issue is present in Fedora 6, at least up to kernel-2.6.19-1.2895.fc6
or thereabouts.

The manual workaround, I'm told, is to install bcm43xx-fwcutter and follow the
instructions in README.fedora.

Comment 5 pbsdesign 2007-03-17 22:19:23 UTC
I have a bcm43xx pcmcia card that works fine (I used bcm43xx-fwcutter to
generate the firmware from the xp driver) using kernel 2.6.19-1.2895.fc6 - but
using any newer kernels breaks the wireless. 

Comment 6 Chuck Ebbert 2007-03-18 21:30:57 UTC
(In reply to comment #5)
> I have a bcm43xx pcmcia card that works fine (I used bcm43xx-fwcutter to
> generate the firmware from the xp driver) using kernel 2.6.19-1.2895.fc6 - but
> using any newer kernels breaks the wireless. 

You might need newer firmware.

Comment 7 Matthew Miller 2007-04-06 17:25:15 UTC
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]

Comment 8 Christopher Beland 2007-04-06 18:03:40 UTC
As noted above, this is present in released versions of Fedora 6, but I do not
have the power to change the version number assigned to this bug.

Comment 9 Matthew Miller 2007-04-06 18:14:19 UTC
Thanks, and sorry about that. Updated to FC6.

Comment 10 Matthew Miller 2007-04-06 18:15:32 UTC
(clearing needinfo bit)

Comment 11 Julius Smith 2007-06-05 18:43:28 UTC
I too had bcm43xx working, but no longer in the most recent FC6 kernels.  It
originally worked using a jwltest kernel, then it worked in standard FC6
kernels, but now some recent change has evidently broken it.

Comment 12 Christopher Beland 2007-08-26 21:51:08 UTC
Still a problem in Fedora 7, though I do not have permission to change the
indicator.  The hardware is detected, but Anaconda doesn't configure it
properly.  There is no warning message in system-config-network about the
firmware needing an upgrade, though /var/log/messages does contain a helpful
pointer to:

(Which says that the firmware is copyrighted and cannot be freely distributed.)

I think it would be far better to relay the kernel messages, or to put something
in a dialog box recommending checking the firmware, rather than simply ignoring
the hardware.

Comment 13 John W. Linville 2007-08-27 14:45:32 UTC
I'm not sure what part of "cannot be freely distributed" is unclear...

Anyway, rest assured that we are aware of this issue and would very much like 
to resolve it -- there just aren't many options.

Comment 14 Stuart Jansen 2007-08-27 15:12:40 UTC
I'm not sure what part of "give the user a useful explanation" is unclear...

Anyway, rest assured we are annoyed by system-config-network pretending to work
then not and would very much like to resolve it -- there just doesn't seem to be
anyone with the knowledge or will to do it.

Comment 15 John W. Linville 2007-08-27 15:28:13 UTC
Did you forget to attach a patch?

Comment 16 Stuart Jansen 2007-08-27 17:51:36 UTC
Dude, if you plan on just ignoring this bug instead of adding a simple, useful
error message of some type, just say so. Don't pretend a firmware license is
preventing you and don't insult users when they provide feedback.

Comment 17 John W. Linville 2007-08-27 18:28:26 UTC
Your hostility is unwelcome.  Please take it elsewhere.

Comment 15 means "if you have a detailed suggestion, please make it".  
Requesting a "message of some type" leaves lots of room for interpretation.  
If you read comment 12, there is already a "message of some type" 
in /var/log/messages.

Encoding knowledge of every driver that may need firmware or some other 
enablement into system-config-network just doesn't scale and would be a 
maintenance problem.  Without that, system-config-network would have no way to 
know which devices should be ignored (e.g. the ones that need firmware but 
don't have it).

Ideally, we would just ship the required firmware and install it either 
unconditionally or upon detection of the matching hardware.  However, the 
firmware for the devices in question is not provided under any license that 
clearly allows for that.

So while your request may seem reasonable, there is no obvious and reasonable 
way to fulfill it.  Mocking those assigned to work on the bug is unlikely to 

Comment 18 Christopher Beland 2007-08-27 19:04:03 UTC
The actual errors in /var/log/messages I got were:

Aug 26 21:51:29 localhost kernel: b43-phy0 ERROR: Microcode
"bcm43xx_microcode5.fw" not available or load failed.
Aug 26 21:51:29 localhost kernel: b43-phy0 ERROR: You must go to and download the
correct firmware (version 4)
Aug 26 21:51:29 localhost firmware_helper[29110]: Loading of
/lib/firmware/bcm43xx_microcode5.fw for b43 driver failed: No such file or directory
Aug 26 21:51:31 localhost NetworkManager: <WARN> 
nm_device_802_11_wireless_scan(): could not trigger wireless scan on device
 wlan0: Network is down 

It seems NetworkManager knows that *something* is wrong, and the kernel knows
why.  It would be unnecessary to create a database of known hardware problems
for system-config-network if the information from the kernel could be somehow

/var/log/messages isn't a particularly user-friendly place to dump important
messages for everyday users, though it's useful to dump technical information
there in case an everyday user files a bug so they can be asked to check the
logs during the diagnostic process.  A user-friendly notification mechanism
would involve the GUI.  It doesn't so much matter whether it's NetworkManager
spontaneously popping up a notification error when you put the card in (which
would be great) or a big red X in a system-config-network list.  It could even
be something as generic as "Wireless card ___ is not working.  Problem with
hardware, driver, or firmware?"  The point is to give the user a heads-up that
they are having more fundamental problems than simply not having their network
settings input correctly.  Or at least, that's the solution I would propose
which I think would be more useful than making the hardware mysteriously
disappear from system-config-network (as implied by the title of this bug).

Comment 19 John W. Linville 2007-11-02 19:20:31 UTC
I'm sorry, but I don't think this is going to really change.  Either 
eventually we will find a legal way to ship a b43 firmware package and none of 
this will matter, or things will stay as they are and people will have to heed
the information in /var/log/messages.

The suggestions in the last paragraph of comment 18 are outside the scope of a 
kernel bug.  Feel free to raise them in the mailing list for NetworkManager.

Note You need to log in before you can comment on or make changes to this bug.