[conspire] Wireless driver problem

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Tue, 23 Jul 2013 18:18:38 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Bego Gerber <begogerber at chemistswithoutborders.org>
Subject: Re: Your advice requested
Organization: If you lived here, you'd be $HOME already.

Quoting Bego Gerber (begogerber at chemistswithoutborders.org):

> Installed firmware-b43-installer and the WiFi card showed up. Connection
> successful, even with security enabled!

Glad it worked!

> It's all a bit over my head.

If you're interested, I'm up for doing a layman-level explanation.
It follows -- and can be safely ignored if _not_ interested.


The Linux kernel looks around at boot time and says 'OK, what hardware
is in this system?'  Sources of information about currently present
hardware include (notably) a chip called the PCI controller chip.
The kernel says 'Hey, what'cha got?", and the PCI controller chip
answers with a litany of hex information.  You can approximate 
what that binary gibberish looks like by doing 'lspci -n'[1]

Here is the 'lspci -n' output for my workstation:

00:00.0 0600: 8086:2770 (rev 02)
00:01.0 0604: 8086:2771 (rev 02)
00:1c.0 0604: 8086:27d0 (rev 01)
00:1c.1 0604: 8086:27d2 (rev 01)
00:1d.0 0c03: 8086:27c8 (rev 01)
00:1d.1 0c03: 8086:27c9 (rev 01)
00:1d.2 0c03: 8086:27ca (rev 01)
00:1d.3 0c03: 8086:27cb (rev 01)
00:1d.7 0c03: 8086:27cc (rev 01)
00:1e.0 0604: 8086:244e (rev e1)
00:1e.2 0401: 8086:27de (rev 01)
00:1f.0 0601: 8086:27b8 (rev 01)
00:1f.1 0101: 8086:27df (rev 01)
00:1f.2 0101: 8086:27c0 (rev 01)
00:1f.3 0c05: 8086:27da (rev 01)
01:00.0 0300: 10de:0402 (rev a1)
02:00.0 0200: 14e4:1677 (rev 01)

Each line is a device tallied up by the PCI controller chip (and
reachable over the PCI bus), and the third field is a two-part 'PCI ID'
identifier string, where the first part (such as '8086') is a unique
identifier for a particular manufacturer, while the second (such as
'2770') is a unique hex number issued by the manufacturer for a
particular part.

Each Linux kernel includes (in background) a lookup table where it can
dereference from those two numbers what the human-readable manufacturer
name and model number is.

The _master_ list can be found at http://pciids.sourceforge.net/ , the
'PCI ID Repository". The kernel maintainers update their copy from the
master copy.  Looking up 8086:2770 via those Web pages, one finds:

Manufacturer:  Intel Corporation
Part: 82945G or 82945GZ or 82945P or 82945PL Memory Controller Hub
(This is actually the 'northbridge' chip of a motherboard built around 
Intel northbridge and southbridge chips, not an expansion board.)

Doing that same job for '14e4:4311':

Manufacturer:  Broadcom Corporation
Part:  BCM4311 802.11b/g WLAN

A third subfield of the kernel's in-background lookup table says, 
if you encounter _this_ device, you will need to load _this_ driver.  
That information can be supplemented by further clues the kernel's
module-handing helper utilities may find in /etc/modprobe.d/* .

The built-in instructions for a Broadcom BCM4311 say 'You need the b43
module/driver'.  So, your laptop tried -- and initially failed to work
for a subtle reason.

That reason is the 'firmware image' thing.  

What do I mean by 'firmware image'?  I mean very low-level code that
back in the old days (1990s-ish) would have been put in a small ROM (hence,
firmware) on an expansion card such as a PCMCIA or PCI card, to
initialise the hardware.  Some time in the middle 1990s (-ish), the
manufacturers realised they could cut of a few cents off the cost of
hardware by _omitting_ the ROM chip.

Instead, the job normally performed by that ROM was piled onto what was
required from the software _driver_.  Specifically, the chip's
manufacturer (say, Broadcom) developed the low-level code that
_ordinarily_ would have been burned into a ROM, then buried it as a file
into the middle of a binary set of MS-Windows drivers, with instructions
to the OS to fling the contents of the file into the device's memory in
order to initialise it.

You would expect that it's common sense for a company like Broadcom to
contact the Linux and BSD and OpenSolaris communities and say 'Hey,
there's this firmware file we've buried in the middle of the Windows
driver for our BCM4311 wireless chip.  You have our permission to
extract it and bundle it with your OSes.'  That would make sense,
because it would make their hardware usable to more people, hence they'd
sell more.

Problem:  Broadcom is staffed by clueless jackasses, so they've never
been willing to spend postage on _saying so_.  So, it remains unlawful by
default (copyright violation) for Linux (etc.) distributions to bundle
that file.  The distributions thus do the next best thing:  They furnish
tools to semi-automatically download a copy of the Windows driver for
(e.g.) the Broadcom BCM4311, extract the firmware file, give it a
suitable name, and stash a copy under /lib/firmware where the Linux
kernel's utilities can find and use it when loading the b43 driver.

'modprobe' is one of those utilities.  The command 'modprobe b43' 
says 'Try to load the b43 driver and any drivers it might depend on, and
tell me what happens when you try'.

Adding the -r flag, like 'modprobe -r b43' reverses the intention, and
says 'Try to unload the b43 driver and any drivers it might depend on,
and tell me what happens when you try'.


Cutting to the chase:  The moment you installed package
'firmware-b43-installer', the resulting new codes does the
aforementioned fetch and stow of the firmware image for b43 .

_Therefore_, because the sole reason b43 hadn't worked was its lack, b43 
then immediately worked when you did 'modprobe b43' to load it.

The 'iwconfig' utility furnishes a smoketest for (among other things)
checking to see if the wireless interface is suddenly present when it
wasn't before you fixed whatever was broken.

And there ya go.


[1] 'lspci -n' means state numeric data only.  The command name 'lspci'
can be parsed as ls (= list to screen) + pci.

----- End forwarded message -----