Broadcom wifi drivers for Linux, some useful reference material

[utu]

.
How does one know if one has a Broadcom wifi, and if so which one:

knoppix@Microknoppix:~$ lspci -vnn -d 14e4:
0c:00.0 Network controller [0280]: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller [14e4:432b] (rev 01)
    Subsystem: Dell Wireless 1510 Wireless-N WLAN Mini-Card [1028:000d]
    Flags: bus master, fast devsel, latency 0, IRQ 17
    Memory at f69fc000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: <access denied>
    Kernel driver in use: b43-pci-bridge

Mine is a Broadcom BCM4322 version 432b (rev 01), Dell Identification 1510
My laptop is a Dell 1545; this wifi is a recommended replacement with a/b/g/n capability.

Broadcom wifis require proprietary firmware to work.

Broadcom provides the necessary information to compile a wl driver which provides some
capability for some Broadcom wifi devices. A README file at the following reference
indicates, presumably, the totality of wl's applicability, including references to Dell
(Inspiron) part number codes. Although the wl driver itself is not under current
development, this reference is current:
http://www.broadcom.com/support/802.11/linux_sta.php

The b43 open-source project tries to cover all Broadcom wifis.
Their b43 driver supports most, but not all possible Broadcom wifis.
The following reference gives a comprehensive summary of which devices are supported by
b43-project drivers and some commentary regarding wl driver capability.
The b43-project specifically notes it does not provide development support of wl.
http://wireless.kernel.org/en/users/Drivers/b43

In many cases one may find that either wl or b43 will suffice, but there are exceptions.

It is unfortunately the case that these two drivers are incompatible, and cannot both
be installed in the Linux kernel at the same time. If both are available, one or the other
must be blacklisted to keep from attempting to add both to the kernel.

As a practical matter, I prefer to leave the preparation and installation of drivers
to Synaptic. Major distributions like Debian and Ubuntu provide this capability, so this
all boils down to just selecting the correct combination of elements in Synaptics.

For b43, one elects b43 firmware installer and b43 firmware cutter and allows Synaptic
to do its work.

For wl, one elects broadcom-sta in some form and either accepts a pre-compiled driver or
sets up a process to compile a wl driver for a specific kernel.

To see if the b43 driver modules got into the kernel:

knoppix@Microknoppix:~$ lsmod | grep b43
b43                   307683  0 
bcma                   22885  1 b43
mac80211              347664  1 b43
cfg80211              319430  2 b43,mac80211
rng_core                2429  1 b43
ssb                    38530  1 b43
pcmcia                 25374  2 b43,ssb

To verify that Synaptic has/had the b43 necessary material:

knoppix@Microknoppix:~$ dpkg-query -l | grep b43 
ii  b43-fwcutter                1:015-14.1    i386   Utility for extracting Broadcom 43xx firmware
ii  firmware-b43-installer      1:015-14.1    all    Installer package for firmware for the b43 driver

To verify the wifi, wlan0, has a connection (Link Quality=48/70) with my router, BUXL3

knoppix@Microknoppix:~$ iwconfig wlan0
wlan0     IEEE 802.11bg  ESSID:"BUXL3"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:18:01:F3:DB:52   
          Bit Rate=54 Mb/s   Tx-Power=7 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=48/70  Signal level=-62 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:63  Invalid misc:375   Missed beacon:0

To verify the wifi got a DNS assignment (198.168.1.3) from the router

knoppix@Microknoppix:~$ ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 08:3e:8e:74:4b:6d  
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a3e:8eff:fe74:4b6d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:23991 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17001 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:16035031 (15.2 MiB)  TX bytes:3524163 (3.3 MiB)

[utu]

Here's what I get for my Broadcom wifi, even if it doesn't have the necessary firmware:

mint@mint / $ lsmod | grep b43
b43                   387185  0 
bcma                   46670  1 b43
mac80211              596969  1 b43
cfg80211              479757  2 b43,mac80211
ssb                    57932  1 b43

If lsmod | grep b43 looks good, then the open-source part of the b43 driver is in place.
At this point one needs to know the Broadcom firmware is also available, and that there is no rfkill blockage in effect.

To see if the necessary firmware is in place:

mint@mint / $ sudo du -h /lib/firmware/b43
1.1M    /lib/firmware/b43

To see if what the rfkill states are:

mint@mint / $ rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no

If there is a Soft block, then rfkill unblock should remove that impediment.
If there is a Hard block, this means a switch somewhere is set wrong.
On my Inspiron for example, Fn-F2 is a toggle which activates a hardware switch on my wifi.

For reference on rfkill, see: http://wireless.kernel.org/en/users/...ntation/rfkill

[utu]

When I DO get on-line, I usually find something like:

knoppix@Microknoppix:~$ less /var/log/syslog | grep -i renewal Mar 22 08:10:18 Microknoppix dhclient: bound to 192.168.1.3 -- renewal in 38121 seconds.

If I were NOT able to get on-line, I wouldn't see such a renewal message,
but I should note that iwconfig wlan0 would NOT indicate a lan assignment,
such as inet addr:192.168.1.3.

If I am NOT getting a lan assignment, it may be that my router has run out
of lan leases. For example, my router has just four leases to assign;
these are for about 11 hours each. Instead of waiting hours for new leases
to become available, an alternative would be to re-cycle my router; that is,
just turn it off, wait ten seconds, then turn it back on. This would cancel
all current leases, and would then allow new ones to be assigned immediately.

This snag might occur after repeated seemingly unsuccessful attempts have been
made to get on-line while making parameter changes and not noticing a few
succesful prior results which have used up the small number of available lan
leases. If all else fails, and it seems like you should be able to get on-line,
and you can't think of anything else to twiddle: recyle the router;
it can't hurt, and that might have been the final hold-up.