b43 firmware & fwcutter
Discussion from ArchWiki "Loading the b43/b43legacy kernel module".
How does it (the package b43-fwcutter) relate to the external scripts and/or the AUR packages listed?
Can it (the package b43-fwcutter) be used to replace the manual download explained below (on ArchWiki "Loading the b43/b43legacy kernel module")?
Summary of options
- ArchWiki "Loading the b43/b43legacy kernel module" has a couple leads:
- An install script at www.lwfinger.com/b43-firmware downloads broadcom-wl-5.100.138.
- The b43-firmware AUR package contains two PKGBUILD files:
Basically all of the packages have the same approach to cutting out the firmware. It's just a different version of the driver. I don't know what's the difference,
but I'm going to go try them all out. The experiment results from trying the 3 firmware versions on my [14e4:4315] LP-PHY rev 01 are on this google sheet. Dustmote (talk)
broadcom-wl work well
I'm running a new dv7-7000 with a Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01). I could not get this to work with the kernel drivers. The signal was so weak it wouldn't obtain an IP address from DHCP, even right next to the AP. Using broadcom-wl did the trick and things are working great.--Skarphace (talk) 05:16, 21 July 2012 (UTC)
Problem with bcm43xx
there is a common problem with some cards managed with the b43 driver, it gets disconnected randomly, with an error in dmesg saying:
kernel: No probe response from AP <addr> after 500ms, disconnecting.
but some googlin' gives the solution, i guess it should be included here as an advice: type the folowing in a shell:
sudo touch /etc/modprobe.d/b43.conf echo "options b43 pio=1 qos=0" | sudo tee -a /etc/modprobe.d/b43.conf
- We don't like putting
cat, etc. in instructions, so if someone does decide that this should be in the main article, make it look similar to this:
- Add the file below:
options b43 pio=1 qos=0
Miscellaneous user notes
This section must be rewritten impersonally, very likely as a FAQ or Troubleshooting section (also remove or update out-of-date information) to be moved to the main article. See also Help:Style.
- In my Dell Inspiron Laptop, I have a Broadcom BCM4401 Ethernet card and a Broadcom BCM4328 wireless card. If I just remove
b43, I can load the
wldriver, but no wireless card shows up. However, if I first remove the
ssb) driver for my Ethernet card, and then load the
wldriver, I get a wireless device using the name eth0. Afterwards, I can load
b44again, to have an Ethernet eth1 device.
- I could not get the BCM4313 chip on a Lenovo B560 to work before following these steps:
- "Load defaults" in the BIOS. After that, the wireless was working under MS Windows. There are not many options in there, so I do not know what the reset may have changed, but it did the trick.
- Blacklist the
acer_wmimodule. For testing, you can add the following to the kernel line in GRUB:
- I have found that to get the
wldrivers working for the Broadcom 4313 chip, you need to blacklist
- --Admiralspark, 20 June 2011
- If you notice slow wireless speeds when your laptop/netbook is not connected to AC power, you may need to disable Wi-Fi power management by adding the following line (assuming wlan0 is your wireless device)
iwconfig wlan0 power offto
/etc/rc.localand create an empty file
/etc/pm/power.d/wireless. In case you also experience interface swapping (discussed above), you might want to add another line for the second interface name as well. The command will have no effect on the wired interface.
- --Tom.yan, 16 August 2011
- In my case on a HP pavilion netbook DM1 with a BCM4313 chip, with the original kernel brcmsmac driver, the LED didn't work, the power was awful, and it kept loosing the signal all the time, unless very close to the Wi-Fi hotspot. The last Broadcom driver
wlsolved everything. So in some cases, it's actually better than the kernel driver. However, I had to install it in the initramfs image, along with lib80211 and lib80211_crypt_tkip to avoid a recurring kernel panic.
- --Ivanoff, 18 March 2012 *Edit* It's all solved with the latest kernel versions. --Ivanoff (talk) 14:19, 14 December 2013 (UTC)
- On a similar HP DM1 netbook I found the brcmsmac driver did not work either. The kernel panic can also be solved by blacklisting the brcmsmac, b43 and wl drivers. In rc.local you can
modprobe wlwithout problems. On a sidenote: I get hard lockups, without any way to debug because there is nothing in kernel.log. Not sure if related to the wl driver though.
- --Wilco, 5 May 2012
- Likewise, my HP Pavilion g7-1374ca also had problems with stock kernel drivers. I downloaded Broadcom tarball, but it wouldn't compile in 3.4.3. I removed the #include <asm/system.h> line and commented out a line referencing .ndo_set_multicast_list (there's only one). Then I was able to compile and load the module for a 100% strength signal, no lockups so far.
- On a Dell Inspiron N5110 with BCM4313, when the wireless was hardware-off, the system would always hang at boot with the kernel
brcmsmacdriver. Using the
broadcom-wldriver the problem was solved.
- --Nplatis, 14 October 2012
- On a Dell M4700 with BCM4313 got hideously slow "performance" with default driver -- switched to broadcom-wl and got near advertised link rate speed (65 to 72 Mb/sec)...until restarting, then was not able to associate with wireless access point. The solution was to blacklist the kernel modules
- --virtualeyes, 23 February 2013
- On a Lenovo G580 mounting a BCM4313 the proprietary driver module kept crashing because some dependencies were unsatisfied (the same problem found by Ivanoff). What worked for me was to put a file in /etc/modprobe.d/ with the following content:
blacklist brcmsmac blacklist bcma softdep wl pre: lib80211_crypt_tkip lib80211_crypt_ccmp lib80211_crypt_wep
- --zarel, 21 June 2013
- On MacBook Pro late 2013 (MacBookPro11,1) with BCM4360 the proprietary STA driver loses connection after running iwconfig (and possibly other software that calls iw_get_ext(..., ..., SIOCGIWTXPOW, ...)) with error messages
kernel: ERROR @wl_dev_intvar_get : error (-1) kernel: ERROR @wl_cfg80211_get_tx_power : error (-1)
Here's a dirty workaround for the kernel
--- /tmp/wireless.h 2014-05-02 04:38:22.403321811 +0400 +++ /usr/src/linux/include/uapi/linux/wireless.h 2014-05-02 04:29:15.291996332 +0400 @@ -283,7 +283,7 @@ #define SIOCSIWFRAG 0x8B24 /* set fragmentation thr (bytes) */ #define SIOCGIWFRAG 0x8B25 /* get fragmentation thr (bytes) */ #define SIOCSIWTXPOW 0x8B26 /* set transmit power (dBm) */ -#define SIOCGIWTXPOW 0x8B27 /* get transmit power (dBm) */ +//#define SIOCGIWTXPOW 0x8B27 /* get transmit power (dBm) */ #define SIOCSIWRETRY 0x8B28 /* set retry limits and lifetime */ #define SIOCGIWRETRY 0x8B29 /* get retry limits and lifetime */ @@ -294,6 +294,8 @@ #define SIOCSIWPOWER 0x8B2C /* set Power Management settings */ #define SIOCGIWPOWER 0x8B2D /* get Power Management settings */ +#define SIOCGIWTXPOW SIOCGIWPOWER + /* WPA : Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WMM). * This ioctl uses struct iw_point and data buffer that includes IE id and len * fields. More than one IE may be included in the request. Setting the generic
- --sbar, 03 May 2014
- On Ahtec PBL01 with wireless controller BCM4313 (using kernel 3.11.0-12 and brcmsmac module) half of times I cannot connect to home wireless network. However I can connect to other networks, for example if I setup my smartphone as access point. What is more confusing is that after connecting to my smartphone network I can switch to my home network and it will connect fine.
- On Lenovo Thinkpad Twist with BCM43228 I was suffering from random disconnections and slow speed when I was connected. I tried the power saving suggestions on the wiki but to no avail. dmesg tail kept giving me this message:
warning: Forced PIO by use_pio module parameter. This should not be needed and will result in lower performance.
This is how /etc/modprobe.d/b43.conf is written:
options b43 pio=1 qos=0
I changed the pio parameter to 0 and which seems to have fixed all of my problems.
- Archiso on a laptop Acer Aspire 5560G with a Broadcom BCM43227 network controller [14e4:4358] does not have access to wifi.
When starting up from the Archiso (from archlinux-2018.12.01-x86_64.iso) the wireless interface is not detected because the wrong module is loaded by default.
Network controller: Broadcom Inc. and subsidiaries BCM43227 802.11b/g/n ... Kernel driver in use: bcma-pci-bridge Kernel modules: bcma, wl
We need to replace the "bcma-pci-bridge" module with wl (broadcom-wl). Here are the modules installed by default:
Module Size Used by ... b43 450560 0 ... wl 6463488 0 ... bcma 61440 1 b43
So we remove the modules b43, bcma, and wl.
rmmod b43 rmmod bcma rmmod wl
We re-add the broadcom-wl module:
Finally we check which is the module used:
Network controller: Broadcom Inc. and subsidiaries BCM43227 802.11b/g/n ... Kernel driver in use: wl Kernel modules: bcma, wl
Ok, we see now that it is the wl module that is loaded for our Network controller.
The interface is then showing up when typing ip link. It is then possible to launch wifi-menu successfully.
You can then install Arch Linux normally. However you will not have the broadcom-wl module in your hard-drive installation with pacstrap. You will have to install the broadcom-wl module into your arch installation from Archiso. In the following instructions you have to replace /dev/sda3 with your partition which was designated as your root ("/") filesystem. For me that is /dev/sda3 .
mount /dev/sda3 /mnt arch-chroot /mnt pacman -S broadcom-wl
Reboot and broadcom-wl will be the module in use for the network controller
The section 'Installation' speculates onAUR:
The DKMS variantAUR
- is kernel agnostic. This means it supports different kernels you may use (e.g.AUR).
- is kernel release agnostic, too. It will be automatically rebuilt after every kernel upgrade or fresh installation. If you useAUR or another kernel release dependant variant (e.g. AUR), it may happen that kernel upgrades break wireless from time to time until the packages are in sync again.
This should probably be noted the package becomes broken every once in a while with new linux-headers incompatible and thus if Wi-fi is your only connection it is dangerous to upgrade the kernel without first checking for package updates (or at least complaints in the discussion.) Bipll (talk) 21:11, 20 March 2017 (UTC)
BCM4331 works better with broadcom-wl-dkms than with b43-firmware
I was having some wifi flakiness issues when using the BCM4331 card with Broadcom wireless#b43 wiki section:AUR, but those issues have been fixed after removing the package and using instead. The following statement appears on the
- BCM4331 noticed to have problems with b43-firmware-classic. Use AUR for this card instead.
For the reasons explained, I think it would be better to suggest the use of community repository.for BCM4331 users, also because the package is already in the
- I can confirm this. On a MacBook Pro 8,1 with BCM4331 wifi is faster and more power efficient (power management didn't work with b43). Recommending instead of b43 with AUR seems to be a better default.
- Aibo (talk) 21:40, 24 March 2019 (UTC)
Installation: broadcom-wl is in the official repos now
The instructions as written are geared towards users performing the initial installation, but the May 2018 ISO will have the binary driver for the stock kernel preinstalled (see FS#58239). The instructions will need to be updated at that time to reference only the rmmod/modprobe bits, and if necessary to describe the manual installation process for users of the non-stock kernel, it should be clearly separated. -- Eschwartz (talk) 02:31, 22 April 2018 (UTC)
Promiscuous mode and MAC spoofing
I am using a mid 2014 (10,2) macbook pro that has the BCM4360 based wireless interface.
It does not support promiscuous mode i.e. it will only accept packets that are either broadcast or for a specific factory MAC address. This also breaks MAC spoofing which which is a desired privacy feature of wifi scanning and accessing public wifi. I think it is worth adding a section about this to make users aware.
An example of a MAC spoofed DHCP request, given real address X and spoofed address Y:
1. Send DHCP request with Y, wireshark confirms that the bytes are set correctly in the request 2. The reply to Y comes in, but the firmware then checks if Y == X, which fails, and drops the packet. Wireshark does not show this because, obviously, the packet is dropped by the firmware. 3. Result: DHCP fails, no connection.
It may also be worth stating the form factor of the daughterboard so that it is easier to find replacements, but perhaps it is better to put that on a macbook specific page. --mf (talk) 13:23, 4 February 2019 (UTC)