OpenWRT Boot Times Affected by WiFi: Difference between revisions

wiki.TerraBase.info
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 89: Line 89:
(57240 - 71000 @ 2160), (40)
(57240 - 71000 @ 2160), (40)
</syntaxhighlight>See?  Now change it back to be legal.
</syntaxhighlight>See?  Now change it back to be legal.
== OpenWrt 25.12.5 USB WiFi and Bluetooth Notes ==
=== MediaTek MT7921AU / USB ID 0e8d:7961 ===
The adapter works with OpenWrt 25.12.5 using:
<pre> apk add kmod-mt7921u </pre>
This installs the required MT76 driver, USB support, common modules and firmware.
Working driver chain:
<pre> mt7921u mt7921_common mt792x_usb mt792x_lib mt76_usb mt76_connac_lib mt76 </pre>
Firmware files:
<pre> /lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin /lib/firmware/mediatek/WIFI_RAM_CODE_MT7961_1.bin </pre>
Successful initialization looks similar to:
<pre> mt7921u 1-1.4:1.0: HW/SW Version: 0x8a108a10 mt7921u 1-1.4:1.0: WM Firmware Version: ____010000 </pre>
The adapter works as an 802.11ax Access Point on both 2.4 GHz and 5 GHz.
=== 6 GHz / NO-IR Problem ===
The MT7921AU reports 6 GHz AP capability, but all 6 GHz channels are marked:
<pre> (no IR) </pre>
NO-IR means ''No Initiating Radiation''. This prevents the radio from starting an Access Point on those channels.
For the United States regulatory domain, OpenWrt's regulatory database contains:
<pre> (5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR </pre>
This can be tested by building a modified regulatory database with only NO-IR removed:
<pre> (5925 - 7125 @ 320), (12), NO-OUTDOOR </pre>
Use the same regulatory database version installed by OpenWrt. For OpenWrt 25.12.5 tested here:
<pre> wireless-regdb-2026.05.30 </pre>
Edit the human-readable source:
<pre> nano db.txt </pre>
Then build the binary database:
<pre> python3 ./db2fw.py regulatory.db db.txt </pre>
''regulatory.db is a compiled binary and should not be edited directly.''
Copy the resulting file to:
<pre> /lib/firmware/regulatory.db </pre>
A fixed 6 GHz channel should be used while testing rather than Auto.
=== Realtek Bluetooth / USB ID 0bda:8771 ===
The existing OpenWrt image already contained the required Bluetooth drivers:
<pre> btusb btrtl bluetooth </pre>
Only the RTL8761BU firmware was missing:
<pre> apk add rtl8761bu-firmware </pre>
After reboot, successful firmware loading was confirmed:
<pre> Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin Bluetooth: hci0: RTL: cfg_sz 6, total sz 30210 Bluetooth: hci0: RTL: fw version 0xdfc6d922 </pre>
Useful verification command:
<pre> dmesg | grep -iE 'hci0|rtl8761|btrtl' </pre>
=== Useful Hardware Identification Commands ===
<pre> lsusb lsusb -t lsmod | grep -E 'mt7921|mt792x|mt76|btusb|btrtl|bluetooth' iw dev iw phy iw reg get wifi status </pre>

Revision as of 18:12, 13 August 2026

...wondering about long boot times for OpenWRT 25.x.y on a WRT32X or similar if a WiFi Channel is set to "Auto"?

Could it really be the fault of a WiFi setting causing long boot times? Believe it or not: YES!

This Needs to be Done on a Full Linux System with Make, Python, etc.

wget https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2026.03.18.tar.xz

Then; tar -xf wireless-regdb-2026.03.18.tar.xz

Go into the directory: cd wireless-regdb-2026.03.18

Edit the db.txt File (ORIGINAL "US Section" is below);

country US: DFS-FCC
	# S1G Channel 1-3
	(902 - 904 @ 2), (30)
	# S1G Channel 5-35
	(904 - 920 @ 16), (30)
	# S1G Channel 37-51
	(920 - 928 @ 8), (30)
	(2400 - 2472 @ 40), (30)
	# 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients
	(5150 - 5250 @ 80), (23), AUTO-BW
	(5250 - 5350 @ 80), (24), DFS, AUTO-BW
	# This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
	# Since 5725 ~ 5730 MHz belongs to the next range which has looser
	# requirements, we can extend the range by 5 MHz to make the kernel
	# happy and be able to use channel 144.
	(5470 - 5730 @ 160), (24), DFS
	(5730 - 5850 @ 80), (31), AUTO-BW
	# https://www.federalregister.gov/documents/2021/05/03/2021-08802/use-of-the-5850-5925-ghz-band
	# max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients
	(5850 - 5895 @ 40), (27), NO-OUTDOOR, AUTO-BW, NO-IR
	# 6g band
	# https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-use-of-the-6ghz-band
	(5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR
	# 60g band
	# reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf
	# channels 1-6 EIRP=40dBm(43dBm peak)
	(57240 - 71000 @ 2160), (40)

...to something similar to what's in the below "Try This..." Section

then;

  • make clean && \
  • make regulatory.db && \
  • scp regulatory.db root@WhatEverIPAddressOfOpenWRTDevice /lib/firmware/regulatory.db (SCP will need to be installed on OpenWRT device)

Just So It's Known

DFS Dynamic Frequency Selection. The radio must check for radar before using that channel as an access point. This can delay wireless startup.

AUTO-BW automatic bandwidth handling inside the regulatory code. It helps determine whether wider channels are allowed across compatible frequency ranges. It does not mean automatic channel selection.

NO-OUTDOOR outdoor use is not allowed for that frequency range.

NO-IR No Initiating Radiation. The device is not allowed to initiate transmissions on that range. In practice, this can prevent access point mode or active scanning.

NO-OFDM Orthogonal Frequency-Division Multiplexing is not allowed. This is mostly relevant to special legacy restrictions.

wmmrule=ETSI ETSI Wireless Multimedia parameters. This affects Quality of Service / contention behavior, not DFS startup delay.

Try This (For Boot Speed Testing ONLY! Transmit Power ONLY changed to verify if OpenWRT does indeed read new config)

country US: DFS-FCC
	# S1G Channel 1-3
	(902 - 904 @ 2), (33)
	# S1G Channel 5-35
	(904 - 920 @ 16), (33)
	# S1G Channel 37-51
	(920 - 928 @ 8), (33)
	(2400 - 2472 @ 40), (33)
	# 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients
	(5150 - 5250 @ 80), (33), AUTO-BW
	(5250 - 5350 @ 80), (33), AUTO-BW
	# This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
	# Since 5725 ~ 5730 MHz belongs to the next range which has looser
	# requirements, we can extend the range by 5 MHz to make the kernel
	# happy and be able to use channel 144.
	(5470 - 5730 @ 160), (33), AUTO-BW
	(5730 - 5850 @ 80), (33), AUTO-BW
	# https://www.federalregister.gov/documents/2021/05/03/2021-08802/use-of-the-5850-5925-ghz-band
	# max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients
	(5850 - 5895 @ 40), (33), AUTO-BW
	# 6g band
	# https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-use-of-the-6ghz-band
	(5925 - 7125 @ 320), (12), AUTO-BW
	# 60g band
	# reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf
	# channels 1-6 EIRP=40dBm(43dBm peak)
	(57240 - 71000 @ 2160), (40)

See? Now change it back to be legal.


OpenWrt 25.12.5 USB WiFi and Bluetooth Notes

MediaTek MT7921AU / USB ID 0e8d:7961

The adapter works with OpenWrt 25.12.5 using:

 apk add kmod-mt7921u 

This installs the required MT76 driver, USB support, common modules and firmware.

Working driver chain:

 mt7921u mt7921_common mt792x_usb mt792x_lib mt76_usb mt76_connac_lib mt76 

Firmware files:

 /lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin /lib/firmware/mediatek/WIFI_RAM_CODE_MT7961_1.bin 

Successful initialization looks similar to:

 mt7921u 1-1.4:1.0: HW/SW Version: 0x8a108a10 mt7921u 1-1.4:1.0: WM Firmware Version: ____010000 

The adapter works as an 802.11ax Access Point on both 2.4 GHz and 5 GHz.

6 GHz / NO-IR Problem

The MT7921AU reports 6 GHz AP capability, but all 6 GHz channels are marked:

 (no IR) 

NO-IR means No Initiating Radiation. This prevents the radio from starting an Access Point on those channels.

For the United States regulatory domain, OpenWrt's regulatory database contains:

 (5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR 

This can be tested by building a modified regulatory database with only NO-IR removed:

 (5925 - 7125 @ 320), (12), NO-OUTDOOR 

Use the same regulatory database version installed by OpenWrt. For OpenWrt 25.12.5 tested here:

 wireless-regdb-2026.05.30 

Edit the human-readable source:

 nano db.txt 

Then build the binary database:

 python3 ./db2fw.py regulatory.db db.txt 

regulatory.db is a compiled binary and should not be edited directly.

Copy the resulting file to:

 /lib/firmware/regulatory.db 

A fixed 6 GHz channel should be used while testing rather than Auto.

Realtek Bluetooth / USB ID 0bda:8771

The existing OpenWrt image already contained the required Bluetooth drivers:

 btusb btrtl bluetooth 

Only the RTL8761BU firmware was missing:

 apk add rtl8761bu-firmware 

After reboot, successful firmware loading was confirmed:

 Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin Bluetooth: hci0: RTL: cfg_sz 6, total sz 30210 Bluetooth: hci0: RTL: fw version 0xdfc6d922 

Useful verification command:

 dmesg | grep -iE 'hci0|rtl8761|btrtl' 

Useful Hardware Identification Commands

 lsusb lsusb -t lsmod | grep -E 'mt7921|mt792x|mt76|btusb|btrtl|bluetooth' iw dev iw phy iw reg get wifi status