[conspire] Wireless driver problem

Tue Jul 23 15:57:52 PDT 2013

Yep, as predicted, the bog-standard b43 driver needed only the required
firmware image file to work, and Bego just hadn't thought to fetch it.

----- Forwarded message from Bego Gerber <begogerber at chemistswithoutborders.org> -----

Date: Tue, 23 Jul 2013 15:54:32 -0700
From: Bego Gerber <begogerber at chemistswithoutborders.org>
To: 'Rick Moen' <rick at linuxmafia.com>
Subject: RE: (forw) Re: Your advice requested

You're a star, Rick!

It's all a bit over my head. 14e4:4311. Module wl not found

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

Thanks, Rick, that's super! I really appreciate your time. 

Happy travels.

Peace,

Bego

 -----Original Message-----
From: Rick Moen [mailto:rick at linuxmafia.com] 
Sent: Tuesday, July 23, 2013 11:38 AM
To: Bego Gerber
Subject: (forw) Re: Your advice requested

Bego, I know I handed you a lot of text, but it boiled down to

(1) my request that you get the output of 'lspci -vnn -d 14e4:' (just
    to be absolutely certain of what Broadcom thing you have)
(2) a probable complete solution to your problem that you 
    can _likely_ carry out simply at home without needing
    to wait until you can visit.

At your convenience, any time you have free time and are motivated, I'd
welcome any reaction / results / thoughts.  ;->

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

Date: Mon, 22 Jul 2013 17:03:20 -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):

> Thank you, Rick,
> 
> That's an irresistible offer. Would Thursday evening work for you
> about 7:30 or 8, or later? I have a 6 PM phone appointment which
> should last less than an hour. I'm already booked the other nights
> this week. 

There's a probable conflict on my end, Thursday evening, as I will
probably need to visit San Francisco International Airport to pick up my
wife who's arriving home from abroad.  So, sounds like next week at 
earliest.

> Lspci output says Network controller: Broadcom Corporation BCM4311 802.11b/g
> WLAN (rev 01).
> 
> The Ethernet controller is BCM4401-B0 100Base-TX (rev 02).

OK, thanks.  BCM4311 is what I really needed to know and will permit me
to do research.  (Just to confirm:  You don't have ethernet-driver
problems, right?  I ask just to make sure I"m not misinterpreting 
your inclusion of the ethernet-device string, which I didn't request.)

And, actually, sorry to trouble you again, but what would be ideal would
be if you could quote the full lspci line for the BCM4311 chip,
including the PCD-ID string.

The PCI-ID string should be one of these three, unless Broadcom has been
playing games again (by which I mean, introducing a radically different
chip claiming to be the same chip identity as older ones that were known
quantities):

14e4:4311 
14e4:4312 
14e4:4313 

Suggestion:  Run this command to collect the PCI-ID data:

lspci -vnn -d 14e4:

'14e4' is a PCI-ID prefix that identifies a Broadcom product.   The
closing four digits after the colon identify the _specific_ Broadcom 
product.

Just as a preview of where we're going:  We are likely to end up using
the Linux kernel's b43 driver, or the Linux kernel's b43legacy driver 
(the latter being in general deprecated and slowly going away).
My sense is that the correct driver is almost certainly b43.

Both the b43 and b43legacy drivers require that the user also furnish a
so-called 'firmware image' file to initialise the chip at startup time,
a binary file that Broadcom produced for that purpose but (out of
apathy/hostility towards Linux and open source) has not issued
permission for anyone else to distribute.  Therefore, the firmware image
file is, in general, not included in Linux distributions, because 
doing so would be technical copyright violation.

Linux distributions tend to furnish open source tools to
semiautomatically fetch Broadcom's file (which Broadcom makes available
to the public hidden deep in a Microsoft Windows driver set, if memory
serves), pull just that one file out of the Broadcom download and give
it the necessary local filename, and write it to the necessary local
directory under /lib/firmware so that the booting Linux kernel can find
it on subsequent reboots.

http://wireless.kernel.org/en/users/Drivers/b43#firmware

If you haven't done that (on Linux Mint, by installing package
'firmware-b43-installer'), then that _may_ be your only problem.
Doing that may make everything work for you (after reboot).

(Specifically, did you install a firmware image file?  If no, that's
actually good news because it's probably your main and possibly sole
blocker, right there.)

The Linux kernel's wireless project page stresses:

  'The 802.11a part of the 4311 is not supported'.

That would imply that if you have a BCM-4311 device with PCI-ID 14e4:4313,
which (I gather) does _only_ 802.11a wireless mode, then the current b43
and b43-legacy drivers will not work, and you'd have to use a
proprietary driver, specifically the broadcom-wl one.

I should note:

> The Dell driver for this Latitude D520 is R242906.exe which I have
> downloaded. I also downloaded the Broadcom driver from this page:
> http://www.broadcom.com/support/802.11/linux_sta.php. 

Here's an unfortunate fact:  People in your situation, in some cases, 
in effect damage their Linux installations after repeated efforts to 
install prprietary kernel drivers that they download from hardware
manufacturer sites.

1.  Proprietary driver option #1.  Above, you are referencing Broadcom's
proprietary broadcom_wl (also known as linux_sta) driver whose module
name is 'wl'.

2.  Proprietary driver option #2.  Dell's R242906.exe downloadable file
provides MS-Windows XP and MS-Windows XP x86 drivers for Broadcom
BCM43xx-series chipse.  That would be usable on Linux using shim tool
ndiswrapper to leverage the functionality of a 'foreign' other-OS binary
driver via its NDIS programming interface.  (You probably know all this
already.)

If a proprietary driver is necessary, it necessary.  No argument.  
The problem is, if you hook one of them into your system, you may have
problems removing it if you need / want to reverse course and try
something else.

The same page I mentioned above also has this sublink that is probably
very useful in such situations:
http://wireless.kernel.org/en/users/Drivers/b43#Switching_between_drivers

Given installation of the firmware file:

As root (do 'sudo su -'.)

modprobe -r b43 bcma
modprobe -r brcmsmac bcma
modprobe -r wl
modprobe b43

See if 'iwconfig' now shows your wireless device.

A similar (but slight different) runaround would be necessary to ensure
that conflicting drivers are no longer present before loading either
ndiswrapper + the Win32 driver or Broadcom's wl module.

With either ndiswrapper + the Win32 driver or Broadcom's wl module, you
would not need to separately furnish the firmware file, because they
have the Broadcom, Inc. secret sauce already built in (per my
recollection, at least).

My _personal_ opinion is that many Linux novices are way, way, way too
quick to resort to proprietary drivers before making a proper effort to
make the default open source ones work.  (The most common error for
wireless cards is to be unaware of the need for a firmware image.)  In
my experience, they are often encouraged in that tactical error by bad
advice gotten on Web forums -- particularly Ubuntu and Linux Mint users
on such forums.  Then, the user, often as not, gets his/her system
thoroughly messed up by doing surgery for the sake of the proprietary
drivers, and sometimes in extreme cases is best advised to reinstall and
try again -- but one can hope that is not the case for your friend's
system.

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

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