[conspire] Fedora 12 wireless hell

Rick Moen rick at linuxmafia.com
Thu Apr 22 01:16:19 PDT 2010

Quoting Ehud Kaldor (ehud.kaldor at gmail.com):

> i tip my (red) hat to you, Rick.
> you were wrong about the dell model. it was 1397 (mental note: don't write
> model numbers from memory). 

Aha!  Well, it being a Dell Wireless 1397 rather than the Dell Wireless 
1370 you initially reported indeed clears up that one mystery:  That
confirms that indeed the card uses a Broadcom BCM4312 chipset, as lspci

> while i was looking for a fedora resource, the answer, as usual, laid
> in the most (un)expected place - Dell. the community blog post you
> have below led me to the broadcom site, downloaded the 32bit one,
> untar, make, make install and reboot. all the fog clears.


I'm delighted that worked for you -- _but_ the problem with relying on
Dell and Broadcom is that they push you towards really bad, buggy, and
brittle proprietary drivers, every single time, even where the
alternative open source drivers are already better.  In this case, they
pushed you towards using proprietary binary MS-Windows NDIS-type drivers
communicated with using the nsdiswrapper shim software. 

I have no personal experience with the open source driver alternative in
this case, b43.  Part of the reason for that is that I try to avoid
Broadcom chipsets wherever humanly possible.  _However_,
proprietary-software workarounds should IMO be one's last resort, after
open source has proven insufficiently mature to the needs of the
situation, rather than the first resort.

I'm saying that for primarily pragmatic reasons:  I've been bitten way
too often by unnecessary early resort to proprietary drivers, which are
unmaintainable, introduce mysterious bugs into kernelspace, and break at
unexpected times upon routine upgrades -- not to mention being a
security liability.  Bad juju.

> this experience, however, brought me to the following conclusion - there is
> a misunderstanding about default driver sets with OS vendors (not just
> Linux, i guess). it is clear to me that in today's world, where laptops are
> prevalent, if display, keyboard and mouse drivers are P0, the next in line
> should be the wireless. 

Problem:  As I said, companies like Broadcom design a lot of their newer
chipsets, especially the really cheap ones, to require loading
proprietary BLOBs into memory in place of ROM-based firmware, in order
to initialise the hardware and provide key low-level functions.  And
they build those 'firmware' binary image files into MS-Windows software,
which they licence to OEMs such as Dell, which thus have the right to
hand out the MS-Windows driver software to their customers.

_However_, companies like Broadcom do not bother to give to anyone --
neither to the OEMs nor to anyone else, and certainly not to the open
source community -- the legal right to redistribute those 'firmware'
image files otherwise.  So, for example, Red Hat, Inc. probably would
dearly love to include the BCM4312 'firmware' file in Fedora 12 master
installation media, so that the kernel's hotplug daemon could autload it
into hardware-related memory at boot time.  _But_ they cannot do so
without violating Broadcom's copyrights.  Because Broadcom doesn't give
a damn, and shoots its customers in the foot without thinking.  To the
extent they _or_ Dell thinks about Linux, their solution is crummy,
buggy, fragile, reuse of proprietary MS-Windows drivers using
ndiswrapper -- which is a really poor solution.

So, yeah, the next in line should be wireless.  I'd predict, just based
on general experience with Fedora, that Fedora 12 includes a recent copy
of the b43 driver.  If so, all it needs is the 'firmware' image file to
initialise Broadcom's hardware.  Which it cannot lawfully include in
Fedora itself.

What Fedora 12 _can_ do, and possibly does, is include software such as
the fw-cutter or b43-fwcutter ('fw' = firmware) utility, which one can
run to autofetch the proprietary MS-Windows driver files, extract just
the 'firmware' images, and hand them to the Linux hotplug facility -- if
I read the docs correctly.

The entire process could be made -more- painless and automatic if
Broadcom decided to stop being dicks and permitted third parties such as
Red Hat, Inc. to lawfully redistribute their 'firmware' files.  Maybe
you could convince them to stop being dicks, but others have tried.

Oddly enough, Ubuntu isn't wiling to violate Broadcom's copyrights,
either.  Here's the explanation on their wiki:

  Installing BCM43xx drivers

  8.04.x (Hardy Heron), 9.04 (Jaunty Jackalope), 9.10 (Karmic Koala),
  10.04 (Lucid Lynx)

  The Ubuntu kernel in versions 8.04.x (Hardy Heron) and higher do provide
  the b43 drivers, however due to copyright restrictions not the
  proprietary firmware which is required to run your card.

  The following instructions explain how to extract the required firmware.

  Internet Access

  If you have some other kind of internet access on your computer, you can
  download the firmware by simply installing the b43-fwcutter package
  which does the download and setup for you automatically.


  To install b43-fwcutter issue the following command in a terminal and
  follow the prompts:
  ~$ sudo apt-get install b43-fwcutter

  No Internet Access

  If you do not have any other means of internet access on your computer,
  you will have to install b43-fwcutter and setup manually (without the
  firmware automatically downloading and being set up).  [...]

> there has got to be a way, like for displays or keyboards, that will
> let you have basic wireless functionality for _ANY_ wireless card,
> enough to connect to the nearest non-customized access-point and
> download the real driver.

Nope.  Don't forget, the problem is that companies like Broadcom are
cheapskates and jerks.  They _could_ make all wireless chipsets support
a least-common-denominator driver interface like, say, the old Lucent
Orinoco 802.11b one, plus a superset that gives their particular
hardware its real appeal and requires fancier drivers.  And then,
everyone could use their Lucent Orinoco drivers for initial Internet
access, which they could use to get better drivers.

However, that would cost them a few more pennies per unit, plus a lot
more competence than they have, plus they would have to care.  But they
don't care, because they're not very good engineers to start with, and
they're dicks.

They're such dicks that they're not even willing to have their staff
attorney issue a one-page letter saying any party has Broadcom's
permission to redistribute their 'firmware' image files without
modification for use to initialise and run their software -- which is
all anyone needs.  For lack of that permission, nobody can ship the
'firmware' file, and something like fw-cutter or b43-fwcuter is
necessary to grab and extract that file off the Internet from Broadcom's
authorised MS-Windows driver files on its authorised download locations.

_Or_, you can use the much worse, Dell-recommended solution of using
_all_ of the MS-Windows drivers (including bundled 'firmware' image
file) using ndiswrapper.  But that will doesn't solve the initial-access
problem you mentioned, which only Broadcom can fix.

The problem is _not_ Linux engineers.  We have great engineers.  The
problem is Broadcom's management being dicks.

Anyway, you might want to switch to the b43 driver, and lose the
proprietary MS-Windows stuff.  I would.

More information about the conspire mailing list