OpenWRT Boot Times Affected by WiFi: Difference between revisions

(5 intermediate revisions by the same user not shown)

Line 1:

== OpenWRT ~~Wireless Regulatory Flags ==~~

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

~~OpenWRT uses~~ the ~~Linux wireless regulatory database to decide which channels, channel widths, and transmit powers are allowed for~~ a ~~selected country code.~~

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

~~A regulatory rule has this general form~~:

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

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

~~<pre>~~

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

~~(frequency_start~~ - ~~frequency_end @ maximum_channel_width), (maximum_power), optional_flags~~

~~</pre>~~

~~Example:~~

~~<pre>~~

~~(5250 - 5350 @ 80), (24), DFS, AUTO-BW~~

~~</pre>~~

~~In that example:~~

* <code>5250 - 5350</code> is the allowed frequency range in MHz.

* <code>@ 80</code> means the maximum allowed channel width is 80 MHz.

* <code>(24)</code> means the maximum transmit power is 24 dBm.

* <code>DFS</code> means Dynamic Frequency Selection is required.

* <code>AUTO-~~BW</code> affects how the regulatory code handles bandwidth across adjacent ranges.~~

~~=== Flag Meanings ===~~

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

~~<code>AUTO~~-~~BW</code> means 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~~.

~~<code>NO-OUTDOOR</code> means outdoor use is not allowed for that frequency range~~.

~~<code>NO~~-~~IR</code> means 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~~.

Go into the directory: cd wireless-regdb-2026.03.18

~~<code>NO-OFDM</code> means Orthogonal Frequency-Division Multiplexing is not allowed. This is mostly relevant to special legacy restrictions.~~

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

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

~~=== Practical Effect ===~~

~~These flags do affect final wireless behavior. They can determine whether OpenWRT, the kernel,~~ the ~~wireless driver, and hostapd allow a radio to start on a given channel~~.

~~For DFS startup testing, the important item~~ is ~~the <code>DFS</code> flag. If the same frequency range starts faster after removing <code>DFS</code>, then DFS/radar handling was part of the delay.~~

~~Changing transmit power alone is not a direct DFS test.~~

~~=== US Regulatory Block ===~~

<pre>

country US: DFS-FCC

# S1G Channel 1-3

Line 75:

Line 38:

# channels 1-6 EIRP=40dBm(43dBm peak)

(57240 - 71000 @ 2160), (40)

</pre>...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 ===

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

<code>AUTO-BW</code> 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.

<code>NO-OUTDOOR</code> outdoor use is not allowed for that frequency range.

<code>NO-IR</code> 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.

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

<code>wmmrule=ETSI</code> 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)

</syntaxhighlight>See? Now change it back to be legal.

=== Oh, One More Thing(s) on WiFi 6E for 6 GHz ===

In /etc/config/wireless, under config wifi-device 'WhatEverRadio'<syntaxhighlight lang="text">

list hostapd_options 'he_6ghz_max_mpdu=0'

list hostapd_options 'he_6ghz_max_ampdu_len_exp=0'

list hostapd_options 'he_6ghz_rx_ant_pat=0'

list hostapd_options 'he_6ghz_tx_ant_pat=0'

</syntaxhighlight>And there's some information that indicates these channels need to be chosen;<syntaxhighlight lang="text">

5, 21, 37, 53, 69, 85, 101, 117, 133, 149, 165, 181, 197, 213, 229

</syntaxhighlight>

== ChatGPTs version of the same thing as above (just so you know a human wrote the above and a moron wrote the below) ==

=== MediaTek MT7921AU 6 GHz / NO-IR Test ===

The MT7921AU worked on 2.4/5 GHz but all 6 GHz channels showed <code>(no IR)</code>. For testing, rebuild the regulatory database with NO-IR removed from the US 6 GHz rule.

Install the required build tools:<pre>

apk add make python3

</pre>Download/extract the same wireless-regdb version used by OpenWrt 25.12.5:<pre>wget https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2026.05.30.tar.xz

tar -xf wireless-regdb-2026.05.30.tar.xz

cd wireless-regdb-2026.05.30</pre>Edit <code>db.txt</code>:<pre>

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

</pre>to:<pre>

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

</pre>Build and install:<pre>python3 ./db2fw.py regulatory.db db.txt

cp regulatory.db /lib/firmware/regulatory.db

reboot</pre>Verify:<pre>

iw reg get

iw phy phy1 info

</pre><code>regulatory.db</code> is binary; edit <code>db.txt</code>, not <code>regulatory.db</code>.

== ...shall we critique? ==

Hmmm, commands and general notes put into the same PRE sections, that's good (NOT!). Un-abstracted the make process, just a different way to do it. Didn't back up existing files. Poor wording. Got a headache now. Solution? Minimize AI usage and just think. Oh, and it left out a bunch of stuff too.

Gave it a second shot where it was more vague on the db.txt stuff, commands were much better, plus it added in the stuff it forgot, but then it got chatty, as if it were being paid by the word. Left other information out.

== Second Shot for ChatGPT ==

=== Regulatory database ===

Modify the US 6 GHz rule in ''db.txt'' to permit AP operation:<pre>

(5925 - 7125 @ 320), (12)

</pre>Build and install:<pre>

opkg update

opkg install make python3

ln -sf /usr/bin/python3 /usr/bin/python

cd /usr/src/wireless-regdb-2026.05.30

make clean

make regulatory.db

cp -f regulatory.db /lib/firmware/regulatory.db

reboot

</pre>Verify:<pre>

iw reg get

</pre>

=== 6 GHz radio ===

Use a fixed 6 GHz Preferred Scanning Channel (PSC); channel 5 worked. Do not use ''auto''.<pre>

uci set wireless.radio1.band='6g'

uci set wireless.radio1.channel='5'

uci set wireless.radio1.country='US'

uci set wireless.radio1.htmode='HE80'

</pre>The MT7921U driver rejected hostapd's default HE 6 GHz capabilities. These four overrides were required:<pre>uci add_list wireless.radio1.hostapd_options='he_6ghz_max_mpdu=0'

uci add_list wireless.radio1.hostapd_options='he_6ghz_max_ampdu_len_exp=0'

uci add_list wireless.radio1.hostapd_options='he_6ghz_rx_ant_pat=0'

uci add_list wireless.radio1.hostapd_options='he_6ghz_tx_ant_pat=0'

uci commit wireless

wifi reload</pre>Without those overrides hostapd failed with:<pre>

The driver does not support the configured HE 6 GHz Max MPDU length

</pre>Use normal '''AP''' mode rather than WDS. After changing WDS settings, reboot if ''/var/run/hostapd-phy1.conf'' retains stale ''wds_sta=1''.

Verify operation:<pre>

ubus list 'hostapd.*'

iw dev

</pre>Working state showed ''hostapd.phy1-ap0'' and 6 GHz channel 5 (5975 MHz).

@@ Line 1: / Line 1: @@
-== OpenWRT Wireless Regulatory Flags ==
+...wondering about long boot times for OpenWRT 25.x.y on a WRT32X or similar if a WiFi Channel is set to "Auto"?
-OpenWRT uses the Linux wireless regulatory database to decide which channels, channel widths, and transmit powers are allowed for a selected country code.
+Could it really be the fault of a WiFi setting causing long boot times?  Believe it or not: YES!
-A regulatory rule has this general form:
+=== This Needs to be Done on a Full Linux System with Make, Python, etc. ===
+wget <nowiki>https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2026.03.18.tar.xz</nowiki>
-<pre>
+Then; tar -xf wireless-regdb-2026.03.18.tar.xz
-(frequency_start - frequency_end @ maximum_channel_width), (maximum_power), optional_flags
-</pre>
-Example:
-<pre>
-(5250 - 5350 @ 80), (24), DFS, AUTO-BW
-</pre>
-In that example:
-* <code>5250 - 5350</code> is the allowed frequency range in MHz.
-* <code>@ 80</code> means the maximum allowed channel width is 80 MHz.
-* <code>(24)</code> means the maximum transmit power is 24 dBm.
-* <code>DFS</code> means Dynamic Frequency Selection is required.
-* <code>AUTO-BW</code> affects how the regulatory code handles bandwidth across adjacent ranges.
-=== Flag Meanings ===
-<code>DFS</code> means Dynamic Frequency Selection. The radio must check for radar before using that channel as an access point. This can delay wireless startup.
-<code>AUTO-BW</code> means 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.
-<code>NO-OUTDOOR</code> means outdoor use is not allowed for that frequency range.
-<code>NO-IR</code> means 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.
+Go into the directory: cd wireless-regdb-2026.03.18
-<code>NO-OFDM</code> means Orthogonal Frequency-Division Multiplexing is not allowed. This is mostly relevant to special legacy restrictions.
+Edit the db.txt File (ORIGINAL "US Section" is below);<pre>
-<code>wmmrule=ETSI</code> applies ETSI Wireless Multimedia parameters. This affects Quality of Service / contention behavior, not DFS startup delay.
-=== Practical Effect ===
-These flags do affect final wireless behavior. They can determine whether OpenWRT, the kernel, the wireless driver, and hostapd allow a radio to start on a given channel.
-For DFS startup testing, the important item is the <code>DFS</code> flag. If the same frequency range starts faster after removing <code>DFS</code>, then DFS/radar handling was part of the delay.
-Changing transmit power alone is not a direct DFS test.
-=== US Regulatory Block ===
-<pre>
 country US: DFS-FCC
 	# S1G Channel 1-3
@@ Line 75: / Line 38: @@
 	# channels 1-6 EIRP=40dBm(43dBm peak)
 	(57240 - 71000 @ 2160), (40)
+</pre>...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 ===
+<code>DFS</code> Dynamic Frequency Selection. The radio must check for radar before using that channel as an access point. This can delay wireless startup.
+<code>AUTO-BW</code> 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.
+<code>NO-OUTDOOR</code> outdoor use is not allowed for that frequency range.
+<code>NO-IR</code> 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.
+<code>NO-OFDM</code> Orthogonal Frequency-Division Multiplexing is not allowed. This is mostly relevant to special legacy restrictions.
+<code>wmmrule=ETSI</code> 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) ===
+<syntaxhighlight lang="text">
+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)
+</syntaxhighlight>See?  Now change it back to be legal.
+=== Oh, One More Thing(s) on WiFi 6E for 6 GHz ===
+In /etc/config/wireless, under config wifi-device 'WhatEverRadio'<syntaxhighlight lang="text">
+list hostapd_options 'he_6ghz_max_mpdu=0'
+list hostapd_options 'he_6ghz_max_ampdu_len_exp=0'
+list hostapd_options 'he_6ghz_rx_ant_pat=0'
+list hostapd_options 'he_6ghz_tx_ant_pat=0'
+</syntaxhighlight>And there's some information that indicates these channels need to be chosen;<syntaxhighlight lang="text">
+, 21, 37, 53, 69, 85, 101, 117, 133, 149, 165, 181, 197, 213, 229
+</syntaxhighlight>
+== ChatGPTs version of the same thing as above (just so you know a human wrote the above and a moron wrote the below) ==
+=== MediaTek MT7921AU 6 GHz / NO-IR Test ===
+The MT7921AU worked on 2.4/5 GHz but all 6 GHz channels showed <code>(no IR)</code>. For testing, rebuild the regulatory database with NO-IR removed from the US 6 GHz rule.
+Install the required build tools:<pre>
+apk add make python3
+</pre>Download/extract the same wireless-regdb version used by OpenWrt 25.12.5:<pre>wget https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2026.05.30.tar.xz
+tar -xf wireless-regdb-2026.05.30.tar.xz
+cd wireless-regdb-2026.05.30</pre>Edit <code>db.txt</code>:<pre>
+(5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR
+</pre>to:<pre>
+(5925 - 7125 @ 320), (12), NO-OUTDOOR
+</pre>Build and install:<pre>python3 ./db2fw.py regulatory.db db.txt
+cp regulatory.db /lib/firmware/regulatory.db
+reboot</pre>Verify:<pre>
+iw reg get
+iw phy phy1 info
+</pre><code>regulatory.db</code> is binary; edit <code>db.txt</code>, not <code>regulatory.db</code>.
+== ...shall we critique? ==
+Hmmm, commands and general notes put into the same PRE sections, that's good (NOT!).  Un-abstracted the make process, just a different way to do it.  Didn't back up existing files.  Poor wording. Got a headache now.  Solution?  Minimize AI usage and just think.  Oh, and it left out a bunch of stuff too.
+Gave it a second shot where it was more vague on the db.txt stuff, commands were much better, plus it added in the stuff it forgot, but then it got chatty, as if it were being paid by the word.  Left other information out.
+== Second Shot for ChatGPT ==
+=== Regulatory database ===
+Modify the US 6 GHz rule in ''db.txt'' to permit AP operation:<pre>
+(5925 - 7125 @ 320), (12)
+</pre>Build and install:<pre>
+opkg update
+opkg install make python3
+ln -sf /usr/bin/python3 /usr/bin/python
+cd /usr/src/wireless-regdb-2026.05.30
+make clean
+make regulatory.db
+cp -f regulatory.db /lib/firmware/regulatory.db
+reboot
+</pre>Verify:<pre>
+iw reg get
 </pre>
+=== 6 GHz radio ===
+Use a fixed 6 GHz Preferred Scanning Channel (PSC); channel 5 worked.  Do not use ''auto''.<pre>
+uci set wireless.radio1.band='6g'
+uci set wireless.radio1.channel='5'
+uci set wireless.radio1.country='US'
+uci set wireless.radio1.htmode='HE80'
+</pre>The MT7921U driver rejected hostapd's default HE 6 GHz capabilities.  These four overrides were required:<pre>uci add_list wireless.radio1.hostapd_options='he_6ghz_max_mpdu=0'
+uci add_list wireless.radio1.hostapd_options='he_6ghz_max_ampdu_len_exp=0'
+uci add_list wireless.radio1.hostapd_options='he_6ghz_rx_ant_pat=0'
+uci add_list wireless.radio1.hostapd_options='he_6ghz_tx_ant_pat=0'
+uci commit wireless
+wifi reload</pre>Without those overrides hostapd failed with:<pre>
+The driver does not support the configured HE 6 GHz Max MPDU length
+</pre>Use normal '''AP''' mode rather than WDS.  After changing WDS settings, reboot if ''/var/run/hostapd-phy1.conf'' retains stale ''wds_sta=1''.
+Verify operation:<pre>
+ubus list 'hostapd.*'
+iw dev
+</pre>Working state showed ''hostapd.phy1-ap0'' and 6 GHz channel 5 (5975 MHz).