Bug 183273

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.

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.

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.

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.

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. 

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

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

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.

Thanks, and sorry about that. Updated to FC6.

(clearing needinfo bit)

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.

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: http://linuxwireless.org/en/users/Drivers/b43#devicefirmware

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

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.

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.

Did you forget to attach a patch?

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.

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

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
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware 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
captured.

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

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.