Broadcom Corporation BCM4311, BCM4312, BCM4313, BCM4321, BCM4322, BCM43224, BCM43225, BCM43227 and BCM43228 Based Wireless NICs
These chipsets are not natively supported by CentOS.
This page is currently maintained by: Miloš Blažević
ATTENTION: Ever since the driver release 18.104.22.168 in December 2010, up to the latest available release (22.214.171.124), no solid evidence has been provided to prove the functionality of these driver versions on CentOS 5 for all wireless chips they supposedly support. Hence, if ELRepo kmod-wl page doesn't help you set up your wireless, you may want to consider falling back to alternative approach by downloading an older driver version from alternate locations, like the ones here, here, and, if you're willing to pay small amount of cash for it here and compiling it accoring to the manual below. Also, kindly provide feedback on your experiences with Broadcom Wireless, so this manual can be kept up to date and further improved.
NOTE: Due to an excessively restrictive license accompanying this Broadcom driver, the ELRepo repository developers have refrained from supplying it via an rpm package - hence this manual was created with the purpose of providing a single comprehenssive driver installation manual.
NOTE: Only Broadcom BCM4311 and BCM4312 chips have been tested by the author so far.
- Broadcom Corporation BCM4311, BCM4312, BCM4313, BCM4321, BCM4322, BCM43224, BCM43225, BCM43227 and BCM43228 Based Wireless NICs
- Step 1: Determining WLAN chip and installing dependencies
- Step 2: Downloading and extracting Broadcom driver archive
- Step 3: Compiling the Broadcom driver module
- Step 4a: Loading the driver module into kernel
- Step 4b: Loading the driver module into kernel on boot time
- Appendix A: Compiling the (latest?) driver under CentOS 5.6
In order to install Broadcom BCM4311, BCM4312,BCM4313, BCM4321 or BCM4322 based wireless network cards, the next steps should be followed:
Step 1: Determining WLAN chip and installing dependencies
First of all, make sure you are the "proud owner of Broadcom BCM43xx wireless card":
[user@host ~]$ /sbin/lspci | grep Broadcom 0b:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 01)
After the WLAN chip model was determined, make sure you have no missing packages needed at compile-time and install them if you do:
[root@host ~]# yum install kernel-headers kernel-devel gcc
Of course, if you're compiling the driver for Xen kernel (i.e. kernel-xen), you should install kernel-xen-devel instead of kernel-devel.
Step 2: Downloading and extracting Broadcom driver archive
Download the Broadcom BCM43xx linux driver archive from Broadcom Official website (this driver is no longer valid - please refer to the admonition on the top of this page) to your machine and extract it to /usr/local/src/hybrid-wl and feel free to change the ownership of the directory and it's contents to some unprivileged user
[root@host ~]# mkdir -p /usr/local/src/hybrid-wl [root@host hybrid-wl]# cd /usr/local/src/hybrid-wl [root@host hybrid-wl]# tar xvfz /path/to/the/tarball/hybrid-portsrc-x86_64-v126.96.36.199.3.tar.gz (name of the downloaded file) [root@host hybrid-wl]# chown -R someuser.somegroup /usr/local/src/hybrid-wl
NOTE: Why not extract it to arbitrary location and leave the ownership it is?
Step 3: Compiling the Broadcom driver module
Driver module can be compiled as follows:
[user@host hybrid-wl]$ make -C /lib/modules/`uname -r`/build/ M=`pwd`
Mind the quotes (i.e. back quotes).
Now, it's very likely you'll get an error message instead of compiled driver module (in fact, different scenario other that this error message is unknown to the author). The message should look something like this:
make: Entering directory `/usr/src/kernels/2.6.18-164.el5-x86_64' LD /tmp/hybrid/hybrid/hybrid/built-in.o CC [M] /tmp/hybrid/hybrid/hybrid/src/wl/sys/wl_linux.o In file included from /tmp/hybrid/hybrid/hybrid/src/wl/sys/wl_linux.c:20: /tmp/hybrid/hybrid/hybrid/src/include/typedefs.h:70: error: conflicting types for ‘bool’ include/linux/types.h:36: error: previous declaration of ‘bool’ was here make: *** [/tmp/hybrid/hybrid/hybrid/src/wl/sys/wl_linux.o] Error 1 make: *** [_module_/tmp/hybrid/hybrid/hybrid] Error 2 make: Leaving directory `/usr/src/kernels/2.6.18-164.el5-x86_64'
As you can see, there is a problem with the typedefs.h file at the line 70. To overcome this, comment out block of code beginning at line 70, so it would look like this:
/* #ifndef TYPEDEF_BOOL typedef unsigned char bool; #endif */
This may also be resolved by simply adding the line below at header (regardless the fact that one such line already exists):
Now, try compiling the driver module again:
[user@host hybrid-wl]$ make -C /lib/modules/`uname -r`/build/ M=`pwd`
and the compile output should look something like this:
make: Entering directory `/usr/src/kernels/2.6.18-164.el5-x86_64' CC [M] /tmp/hybrid/hybrid/hybrid/src/wl/sys/wl_linux.o CC [M] /tmp/hybrid/hybrid/hybrid/src/wl/sys/wl_iw.o CC [M] /tmp/hybrid/hybrid/hybrid/src/shared/linux_osl.o LD [M] /tmp/hybrid/hybrid/hybrid/wl.o Building modules, stage 2. MODPOST CC /tmp/hybrid/hybrid/hybrid/wl.mod.o LD [M] /tmp/hybrid/hybrid/hybrid/wl.ko make: Leaving directory `/usr/src/kernels/2.6.18-164.el5-x86_64'
The module, once built, can be stripped of unnecessary symbols:
[user@host hybrid-wl]$ strip --strip-debug wl.ko
What you will notice, is that driver module file size reduces significantly (from 2.2MB to 1.5MB). And yes, your driver module works
Step 4a: Loading the driver module into kernel
Having successfully compiled the driver module, you can now load it into kernel and set up automatic driver load on system boot (to do this, you'll have to assume root privileges). Of course, all this can only be done only after you remove the existing wireless driver modules from kernel (in case these are loaded):
[root@host ~]# rmmod bcm43xx [root@host ~]# rmmod b43 [root@host ~]# rmmod b43legacy [root@host ~]# rmmod ndiswrapper
and now load the driver module:
[root@host hybrid-wl]# insmod wl.ko
In case this fails (there have been quite a few reports, however, this kind of behavior has not yet been witnessed by the author), with an error message like:
insmod: error inserting 'wl.ko': -1 Unknown symbol in module
Try building the module dependencies first:
[root@host ~]# depmod `uname -r`
and then load the driver module:
[root@host hybrid-wl]# modprobe wl
If module loading fails once again, try inserting ieee802.11_crypt_tkip module dependency manually first, and only then proceed with loading of wl driver module:
[root@host hybrid-wl]# modprobe ieee80211_crypt_tkip [root@host hybrid-wl]# modprobe wl
The 'ndiswrapper' kernel module can be removed provided you didn't use it for anything else but wireless driver, but this is not necessary.
Step 4b: Loading the driver module into kernel on boot time
First of all, copy the driver module file to a location where kernel can find it:
[root@host hybrid-wl]# cp -vi /usr/local/src/hybrid-wl/wl.ko /lib/modules/`uname -r`/extra/
to be consistent with all other external modules that have been / may be installed from a kmod packages (e.g. fuse, ntfs-3g, etc.)
[root@host ~]# depmod $(uname -r)
in order to create a list of module dependencies.
Edit the /etc/modprobe.d/blacklist file adding the lines:
blacklist bcm43xx blacklist ndiswrapper blacklist b43 blacklist b43legacy
By doing so, you're preventing these modules from being loaded into kernel at boot time. Also, if there is a line in the /etc/modprobe.conf assigning the driver to your wireless interface, like:
alias eth1 bcm43xx or alias eth1 b43 or alias eth1 b43legacy
have the line commented out:
#alias eth1 bcm43xx or #alias eth1 b43 or #alias eth1 b43legacy
and add the new driver alias for your wireless card:
alias eth1 wl
All this assuming the device file for your wireless interface is 'eth1'.
Now, edit the /etc/modprobe.d/modprobe.conf.dist file and add the following lines to it (in some cases, the following may not be necessary):
alias ieee80211_crypt_tkip ieee80211_crypt_tkip alias eth1 wl
Your driver should now load every time you reboot (except of course, when you install the new kernel, in which case the driver has to be re-compiled for it following these same steps).
ATTENTION: This driver module is NOT persistent across kernel upgrades (i.e. when you update the kernel, and boot the newly installed one, you'll have to do this over again). And again, this is why you placed the archive contents in /usr/local/src/hybrid-wl and changed the ownership of the directory and it's contents.
NOTE: After successful setup of the driver, users new to wireless often report problems like "Error for wireless request "Set Encode" (8B2A): SET failed on device.... Quick and easy solution is to configure NetworkManager service to manage your network connections instead of the network service.
Appendix A: Compiling the (latest?) driver under CentOS 5.6
Apparently, the functionality problem with the latest release of the driver is not the only one. Instead, another 'compile-time' issue has also arisen with the release of CentOS 5.6, coming into light after commenting out the well know TYPEDEF_BOOL part:
[milos@host hybrid-new]$ make -C /lib/modules/2.6.18-238.5.1.el5/build M=`pwd` make: Entering directory `/usr/src/kernels/2.6.18-238.5.1.el5-x86_64' LD /tmp/hybrid-new/built-in.o CC [M] /tmp/hybrid-new/src/shared/linux_osl.o In file included from /tmp/hybrid-new/src/shared/linux_osl.c:17: /tmp/hybrid-new/src/include/typedefs.h:86: error: conflicting types for ‘bool’ include/linux/types.h:36: error: previous declaration of ‘bool’ was here In file included from /tmp/hybrid-new/src/shared/linux_osl.c:19: /tmp/hybrid-new/src/include/linuxver.h:88: error: redefinition of typedef ‘work_func_t’ include/linux/workqueue.h:22: error: previous declaration of ‘work_func_t’ was here make: *** [/tmp/hybrid-new/src/shared/linux_osl.o] Error 1 make: *** [_module_/tmp/hybrid-new] Error 2 make: Leaving directory `/usr/src/kernels/2.6.18-238.5.1.el5-x86_64'
The issue is easily resolved by commenting out the problematic line 88:
typedef void (*work_func_t)(void *work);
in the file /usr/local/src/hybrid/src/include/linuxver.h.
After the 'removal' of the aforementioned line, the driver compiles nicely. Honestly, compilation of an earlier driver version wasn't attempted so far, so that's exactly the reason for bringing this issue up.