- Broadcom wireless
- History
- Driver selection
- Installation
- brcm80211
- b43
- broadcom-wl
- Offline installation
- Manually
- Known issues
- Ethernet card is not detected
- Troubleshooting
- Setting broadcom-wl in monitor mode
- Device inaccessible after kernel upgrade
- Device with broadcom-wl driver not working/showing
- Interface is showing but not allowing connections
- Suppressing console messages
- Device BCM43241 not detected
- Device BCM43241 EFI Vars
- Connection is unstable with some routers
- No 5GHz for BCM4360 (14e4:43a0) / BCM43602 (14e4:43ba) devices
- Device works intermittently
- SSH freeze for BCM4331 with b43
- Заливаем скетчи в ESP8266, управляем каналами по Wi-Fi, создаем свои сети.
- Paul_B
- gerkimuyda
Broadcom wireless
This article details how to install and setup a Broadcom wireless network device.
History
Broadcom has a noted history with its support for Wi-Fi devices regarding GNU/Linux. For a good portion of its initial history, Broadcom devices were either entirely unsupported or required the user to tinker with the firmware. The limited set of wireless devices that were supported were done so by a reverse-engineered driver. The reverse-engineered b43 driver was introduced in the 2.6.24 kernel.
In August 2008, Broadcom released the 802.11 Linux STA driver officially supporting Broadcom wireless devices on GNU/Linux. This is a restrictively licensed driver and it does not work with hidden ESSIDs, but Broadcom promised to work towards a more open approach in the future.
In September 2010, Broadcom released a fully open source driver. The brcm80211 driver was introduced in the 2.6.37 kernel and in the 2.6.39 kernel it was sub-divided into the brcmsmac and brcmfmac drivers.
The types of available drivers are:
Driver | Description |
---|---|
brcm80211 | Kernel driver mainline version (recommended) |
b43 | Kernel driver reverse-engineered version |
broadcom-wl | Broadcom driver with restricted license |
Driver selection
To know what driver(s) are operable on the computer’s Broadcom wireless network device, the device ID and chipset name will need to be detected. Cross-reference them with the driver list of supported brcm80211 and b43 devices.
Installation
brcm80211
The kernel contains two built-in open-source drivers: brcmfmac for native FullMAC and brcmsmac for mac80211-based SoftMAC. They should be automatically loaded when booting.
- brcmfmac supports newer chipsets, and supports AP mode, P2P mode, or hardware encryption.
- brcmsmac only supports old chipsets like BCM4313, BCM43224, BCM43225.
Chips supported by the brcm80211 driver can be found in [1].
b43
Two reverse-engineered open-source drivers are built-in to the kernel: b43 and b43legacy. b43 supports most newer Broadcom chipsets, while the b43legacy driver only supports the early BCM4301 and BCM4306 rev.2 chipsets. To avoid erroneous detection of your WiFi cards chipset, blacklist the unused driver.
Both of these drivers require non-free firmware to function. Install b43-firmware AUR , b43-firmware-classic AUR , or b43legacy-firmware AUR depending on the chipset.
- If unsure which firmware package you need, check the output of dmesg and search for «b43». If you see a message like Loading firmware b43/ucode4.fw , you need either b43-firmwareAUR or b43-firmware-classicAUR . If you see a message like Loading firmware b43legacy/ucode4.fw , you need the b43legacy-firmwareAUR package.
- BCM4306 rev.3, BCM4311, BCM4312 and BCM4318 rev.2 have been noticed to experience problems with b43-firmware. Use b43-firmware-classicAUR or b43legacy-firmwareAUR for these cards instead.
- BCM4331 noticed to have problems with b43-firmware-classic. Use b43-firmwareAUR for this card instead, or switch to the broadcom-wl mentioned below for a more stable experience.
The b43 should be loaded automatically, but you may need to explicitly load the module at boot.
broadcom-wl
The factual accuracy of this article or section is disputed.
There are two variants of the restrictively licensed driver:
- is kernel agnostic. This means it supports different kernels you may use (e.g. linux-ckAUR ).
- is kernel-release agnostic, too. It will be automatically rebuilt after every kernel upgrade or fresh installation. If you use broadcom-wl or another kernel release dependant variant (e.g. broadcom-wl-ckAUR ), it may happen that kernel upgrades break wireless from time to time until the packages are in sync again.
- will need the linux-headers package for the installed kernel(s) in order to build the module. Those packages are optional to the DKMS package and will need to be installed manually.
Offline installation
An Internet connection is the ideal way to install the broadcom-wl driver; many newer laptops with Broadcom cards forgo Ethernet ports, so a USB Ethernet adapter or Android tethering may be helpful. If you have neither, you will need to first install the base-devel package during installation. Then, use another Internet-connected computer to download linux-headers and the driver tarball from the AUR, and install them in that order.
Manually
Warning: This method is not recommended. Drivers that are un-tracked can become problematic or nonfunctional on system updates.
Install the appropriate driver for your system architecture from the Broadcom website. After this, to avoid driver/module collisions with similar modules and make the driver available, do:
# rmmod b43 # rmmod ssb # modprobe wl
The wl module should automatically load lib80211 or lib80211_crypt_tkip otherwise they will have to be manually loaded.
If the driver does not work at this point, you may need to update dependencies:
If needed, load the module at boot. It is recommended that you blacklist conflicting modules.
Known issues
Ethernet card is not detected
Broadcom wireless module has a history of conflicting with Broadcom Ethernet module.
Due to conflicts between wl (wireless module) and tg3 (Ethernet module), tg3 is now blacklisted as of broadcom-wl-dkms 6.30.223.271-27[2]. See also FS#70476.
This also affects broadcom-wl as it is built based on broadcom-wl-dkms .
Troubleshooting
Setting broadcom-wl in monitor mode
Monitor mode is used to capture 802.11 frames over the air. This can be useful for diagnosing issues on a network or testing the security of your wireless network. Often, monitor mode is required to capture certain frames for wireless penetration testing, but it may be unethical or even illegal to capture frames on any network you do not own, manage or have permission to perform penetration testing against.
To set broadcom-wl in monitor mode you have to set 1 to /proc/brcm_monitor0 :
# echo 1 > /proc/brcm_monitor0
It will create a new network interface called prism0 .
To work in monitor mode, use this newly created network interface.
Device inaccessible after kernel upgrade
Since the 3.3.1 kernel the bcma module was introduced. If using a brcm80211 driver be sure it has not been blacklisted. It should be blackisted if using a b43 driver.
If you are using broadcom-wl , uninstall and reinstall it after upgrading your kernel or switch to broadcom-wl-dkms package.
Device with broadcom-wl driver not working/showing
Be sure the correct modules are blacklisted and occasionally it may be necessary to blacklist the brcm80211 drivers if accidentally detected before the wl driver is loaded. Furthermore, update the modules dependencies depmod -a , verify the wireless interface with ip addr , kernel upgrades will require an upgrade of the non-DKMS package.
Interface is showing but not allowing connections
Suppressing console messages
You may continuously get some verbose and annoying messages during the boot, similar to
phy0: brcms_ops_bss_info_changed: arp filtering: enabled true, count 0 (implement) phy0: brcms_ops_bss_info_changed: qos enabled: false (implement) phy0: brcms_ops_bss_info_changed: arp filtering: enabled true, count 1 (implement) enabled, active
To disable those messages, increase the loglevel of printk messages that get through to the console — see Silent boot#sysctl.
Device BCM43241 not detected
This device will not display with either lspci nor lsusb ; there is no known solution yet.
Device BCM43241 EFI Vars
As per the driver page it may be necessary to copy the efi vars before the driver will operate correctly. However the expected path depends on your system.
. Direct firmware load for bcrm/your driver.your device failed with error -2
Write the efi vars into the referenced location, e.g. on a thinkpad tablet:
$ cat /sys/firmware/efi/efivars/nvram-74b00bd9-805a-4d61-b51f-43268123d113 > /lib/firmware/brcm/brcmfmac43241b5-sdio.LENOVO-20C1002PUK.txt
Connection is unstable with some routers
If no other approaches help, install linux-lts , or use a previous driver version.
No 5GHz for BCM4360 (14e4:43a0) / BCM43602 (14e4:43ba) devices
Issue appears to be linked to a channel issue. Changing the wireless channel to a lower channel number (like 40 or, if your router show MHz instead of channel numbers, like 5200 MHz or 5280 MHz) seems to allow connection to 5GHz bands. If your router has the same SSID for the 2.4GHZ and 5GHZ, this can fix problems with your wireless connection being unstable or very slow.
Device works intermittently
In some cases (e.g. using BCM4331 and b43-firmware AUR ), wifi connection works intermittently. One way to fix this is to check if the card is hard-blocked or soft-blocked by kernel, and if it is, unblock it with rfkill.
SSH freeze for BCM4331 with b43
The b43-firmware AUR driver has been observed hanging in ssh sessions with BCM4331. Installing broadcom-wl and removing b43 solves it.
Заливаем скетчи в ESP8266, управляем каналами по Wi-Fi, создаем свои сети.
Как всегда бывает, мы задаем направление, чтобы человек дальше сам копал («отсюда и до обеда»(с)анекдот), но людям не это надо! Им надо сразу готовый код! И чтобы даже пароли уже были подставлены от их сети.
зы: mesh ведь вроде не позволит параллельно держать связь с домашней сеткой (домашним вайфаем)
Тсссс! Теперь главное не вспугнуть ТС, чтобы он повёлся на этот меш — и мы узнаем много нового и интересного
Как анекдот : бабка, подай провод! Ну вот, я же говорил ноль, а все: фаза, фаза !
Paul_B
Member
#include IPAddress local_IP(192,168,4,22); IPAddress gateway(192,168,4,9); IPAddress subnet(255,255,255,0); void setup() < Serial.begin(115200); Serial.println(); Serial.print("Setting soft-AP configuration . "); // "Задаем настройки программной точки доступа . " Serial.println(WiFi.softAPConfig(local_IP, gateway, subnet) ? "Ready" : "Failed!"); // "Готово" : "Задать настройки не удалось" Serial.print("Setting soft-AP . "); // "Настройка программной точки доступа . " Serial.println(WiFi.softAP("ESPsoftAP_01") ? "Ready" : "Failed!"); // "Готово" : "Настройка не удалась" Serial.print("Soft-AP IP address = "); // "IP-адрес программной точки доступа = " Serial.println(WiFi.softAPIP()); >void loop() <>
у точки доступа ее IP адрес и шлюза разный
IPAddress local_IP(192,168,4,22);
IPAddress gateway(192,168,4,9);
Это как так. А что выступает в качестве шлюза? Домашняя сеть с адресами 192.168.4.* ?
А как быть, если я хочу чтобы адресация была абсолютно жруой и не пересекалась с домашней. И только ESP, на которой реализована AP изредка входила в домашнюю сеть и давала данные. Кстати, как домашняя сеть будет понимать, что подключилась ESP — через имя DNS периодически опрашивать через HTTP?
gerkimuyda
New member
У вас две сети — ваша домашняя, в которой ESP (одна — главная) будет обычным клиентом (ей будет выдавать ИП ваш роутер.)
И вторая сеть — ваши модули (где ваша главная должна иметь статический ИП и поднять свой DHCP)
Так, давайте не спешить и все по порядку делать. С начала напишите из примеров (в ардуине есть пункт меню examples, где есть примеры для ESP) и прошейте отдельно разные модули:
1. модуль обычного клиента для домашней сети с подключением в сеть.
2. модуль, который выступит в роли SoftAP с поднятым DHCP. Который будет иметь свой ИП (например 192.168.10.1) а раздавать другим будет 192.169.10.11-192.168.10.99 маска 255.255.255.0 gw — свой ип (192.168.10.1)
3. модуль, который будет искать главную AP и подключаться к ней, получать с нее настройки!
4. дописать модуль №2, чтобы поднять на нем http-сервер, обслуживающий входящие запросы. Для начала — просто запросы от других модулей (типа «get /check?from=» или «get /online?from=» или «/register?from=») chip_id вносите сразу, по ним вы потом будете разбираться между модулями, где какой, т.к. ip-адреса у них будут меняться. Можете (если надо) также добавить параметр, чтобы модуль сообщал свою роль (пример «get /register?from=C3E4F2&type=Relay4 (модуль с релюшками на 4 канала)
5. дописать модуль №3, чтобы он регистрировался на главном, с передачей нужных параметров, и чтобы периодически сообщал свой онлайн-статус. Можно схитрить, брать из настроек Gataway и считать его ИП-адресом сервера (впоследствии можно будет легко отделить сервер от главной АП, если понадобится)
когда по отдельности все отработаете и разберетесь — тогда можно объединять ваши наработки в один главный модуль (№1 + №2) и чуть позже добавлять к нему №3 учетом алгоритма создания главной АП, если таковой не найдено.
Потом уже спокойно дальше будете наращивать функционал. Маленькими шажочками. На отдельном модуле обкатываете код, потом его интегрируете в ваш основной на другом модуле.
—
— Помните, из домашней сети вы не будете иметь доступа к сети модулей (ихнему вайфаю). Если надо на период отладки — подключайтесь компом к ихнему вайфаю.
— Из домашней сети можно получить доступ только к главной АП, когда она подключится к вашей сети (и то, если вы http-серверу разрешите следить за всеми запросами, а не ограничите его запросами только из сети 192.168.10.*)
— Маршрутизации между интерфейсами вашего главного модуля не будет! Поэтому шлюз для модулей внутренней сети не нужен, т.к. не будет работать, но через него можно передать «на какой ип слать запросы к серверу»