OpenWRT Boot Times Affected by WiFi: Difference between revisions

(4 intermediate revisions by the same user not shown)

Line 1:

...wondering about long boot times for OpenWRT 25.x.y on a WRT32X or similar?

...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 be WiFi ~~related~~? Believe it or not: YES!

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

=== /~~lib~~/~~firmware~~/~~regulatory~~.~~db ===~~

=== 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

Go into the directory: cd wireless-regdb-2026.03.18

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

country US: DFS-FCC

# S1G Channel 1-3

Line 33:

Line 38:

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

(57240 - 71000 @ 2160), (40)

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

</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> ~~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>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> ~~means~~ outdoor use is not allowed for that frequency range.

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

<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> ~~means~~ Orthogonal Frequency-Division Multiplexing is not allowed. This is mostly relevant to special legacy restrictions.

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

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

<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) ===

Line 75:

Line 89:

(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: @@
-...wondering about long boot times for OpenWRT 25.x.y on a WRT32X or similar?
+...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 be WiFi related?  Believe it or not: YES!
+Could it really be the fault of a WiFi setting causing long boot times?  Believe it or not: YES!
-=== /lib/firmware/regulatory.db ===
+=== 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
+Go into the directory: cd wireless-regdb-2026.03.18
+Edit the db.txt File (ORIGINAL "US Section" is below);<pre>
 country US: DFS-FCC
 	# S1G Channel 1-3
@@ Line 33: / Line 38: @@
 	# channels 1-6 EIRP=40dBm(43dBm peak)
 	(57240 - 71000 @ 2160), (40)
-</pre><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.
+</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> 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>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> means outdoor use is not allowed for that frequency range.
+<code>NO-OUTDOOR</code> 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.
+<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> means Orthogonal Frequency-Division Multiplexing is not allowed. This is mostly relevant to special legacy restrictions.
+<code>NO-OFDM</code> Orthogonal Frequency-Division Multiplexing is not allowed. This is mostly relevant to special legacy restrictions.
-<code>wmmrule=ETSI</code> applies ETSI Wireless Multimedia parameters. This affects Quality of Service / contention behavior, not DFS startup delay.
+<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) ===
@@ Line 75: / Line 89: @@
 	(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).