[conspire] Wireless driver problem

Sat Jul 27 18:27:21 PDT 2013

And generally, there'll be a message in the kernel log (you can see it
by typing dmesg) that says something like 'could not load blah blah
blah .fw'

That's the clue that there's a firmware file that needs to be located
and put in /lib/firmware/ someplace

Then it's just a case of locating the file and putting it in the right
place, doing the research, like Rick just did for you.

On Tue, Jul 23, 2013 at 6:20 PM, Rick Moen <rick at linuxmafia.com> wrote:
> ----- 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 -----
>
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire

-- 
--
Best Regards.
This is unedited.