Hi Morse team,
Following up on:
We applied ajudge’s recommended chan_switch syntax (kHz freqs,
prim_bandwidth, sec_channel_offset, no op_class) and the AP-side IE
is now correctly populated (op_bw, prim_bw, vht, ht all non-zero).
After running a 4-step matrix of channel switches in a row on
identical hardware, we found that the STA-side mac80211 behaviour
is NOT intermittent — it’s DETERMINISTIC, depending on which
5 GHz-mapped UNII band the destination falls into:
- Destination mapped into UNII-2C (5500-5720 MHz) — STA follows
the in-band CSA seamlessly, no disconnect, kernel logs
CTRL-EVENT-CHANNEL-SWITCH / morse: post_channel_switch - Destination mapped into UNII-3 (5745-5825 MHz) — STA mac80211
rejects with “switches to unsupported channel … width:5”
and disconnects, full reassoc needed (~28 s downtime)
The dependent variable is the destination’s regdom permissibility
under the cfg80211 compat shim — UNII-3 at 160 MHz width is
restricted by US regdom, UNII-2C at 160 MHz is allowed under DFS.
Full reproduction + logs below.
== Hardware / firmware (both AP and STA) ==
Hardware: MM8108 EKH01 module
Build: rel_1_17_8_2026_Mar_24
- hostapd_s1g rel_1_17_8_2026_Mar_24-1
- wpa_supplicant_s1g rel_1_17_8_2026_Mar_24-1
- kmod-morse 5.15.189+rel_1_17_8_2026_Mar_24-1
- morse-fw-8108 rel_1_17_8_2026_Mar_24-1
- morsectrl rel_1_17_8_2026_Mar_24-1
- morse-regdb v2.7.0-1
- wpad-openssl 2023-09-08-e5ccbfc6-8
- kernel 5.15.189, iw 5.19
Regulatory: country=US, 8 MHz HaLow operation
AP runs hostapd_s1g with FT-SAE enabled per the OpenWrt FT wiki
(ieee80211r=1, mobility_domain=a1b2, ft_psk_generate_local=0,
nas_identifier=, r1_key_holder=,
reassociation_deadline=20000, sae_pwe=0, ieee80211k=1).
Full hostapd-phy0-wlan0.conf in Appendix A.
STA associates with key_mgmt=FT-SAE and we observe auth_alg=ft
on reassoc events — FT itself works fine.
== Test matrix (4 chan_switch invocations, in order, on the same
running pair; CSA-OOB workaround DISABLED throughout) ==
Test 1: 8 MHz CH_28 → 8 MHz CH_44
Test 2: 8 MHz CH_44 → 2 MHz @ 923 MHz (your community example)
Test 3: 2 MHz @ 923 MHz → 8 MHz CH_28
Test 4: 8 MHz CH_28 → 8 MHz CH_44 (repeat of test 1)
== Test 1 — 8 MHz CH_28 → 8 MHz CH_44 ==
AP command:
$ hostapd_cli_s1g -i wlan0 chan_switch 10 920500
prim_bandwidth=1 sec_channel_offset=1
center_freq1=924000 bandwidth=8
OK
AP hostapd log:
hostapd_s1g: wlan0: IEEE 802.11 CHAN_SWITCH EHT config 0x2
HE config 0x2 VHT config 0x1
hostapd_s1g: hostapd_fill_csa_settings : ECSA info op_bw=160,
prim_bw=1, vht=1, ht=1, change to oldconfig:
ht=1, vht=1
AP iw dev wlan0 info post-switch:
channel 149 (5745 MHz), width: 160 MHz, center1: 5815 MHz
STA kernel + supplicant log:
[4414.171472] wlan0: AP 0c:bf:74:00:1f:05 switches to
unsupported channel (5745.000 MHz, width:5,
CF1/2: 5815.000/0 MHz), disconnecting
wpa_supplicant_s1g: wlan0: CTRL-EVENT-DISCONNECTED
bssid=0c:bf:74:00:1f:05 reason=4 locally_generated=1
wpa_supplicant_s1g: wlan0: Added BSSID 0c:bf:74:00:1f:05 into
ignore list, ignoring for 10 seconds
STA recovery: full reassoc ~28 s later.
Result: FAILED — width:5 = NL80211_CHAN_WIDTH_160; 5745 MHz center +
160 MHz width is not in the US 5 GHz regdom permission set
for non-DFS use → mac80211 rejects.
== Test 2 — 8 MHz CH_44 → 2 MHz @ 923 MHz (your community example) ==
AP command:
$ hostapd_cli_s1g -i wlan0 chan_switch 10 922500
prim_bandwidth=1 sec_channel_offset=1
center_freq1=923000 bandwidth=2
OK
AP iw dev wlan0 info post-switch:
channel 157 (5785 MHz), width: 40 MHz, center1: 5795 MHz
STA log: NO new lines from kernel/wpa_supplicant_s1g.
STA iw dev wlan0 link post-switch (no disconnect ever happened):
Connected to 0c:bf:74:00:1f:05 (on wlan0)
SSID: g7-AP-00000001
freq: 5785
RX: 49318 bytes (353 packets) [traffic flowing]
STA wpa_cli status: wpa_state=COMPLETED, key_mgmt=FT-SAE,
freq=5785
Result: ZERO-HANDOFF SUCCESS — STA followed the in-band CSA
seamlessly. width:40 = NL80211_CHAN_WIDTH_40, permitted
freely under US regdom.
== Test 3 — 2 MHz @ 923 MHz → 8 MHz CH_28 ==
AP command:
$ hostapd_cli_s1g -i wlan0 chan_switch 10 912500
prim_bandwidth=1 sec_channel_offset=1
center_freq1=916000 bandwidth=8
OK
AP iw dev wlan0 info post-switch:
channel 100 (5500 MHz), width: 160 MHz, center1: 5570 MHz
STA log (verbatim, demonstrates clean CSA-follow):
[5598.120591] morse: pre_channel_switch: count=4,
target_freq=5500 MHz, blockTX=0
wpa_supplicant_s1g: wlan0: CTRL-EVENT-STARTED-CHANNEL-SWITCH
freq=5500 ht_enabled=1 ch_offset=1
ch_width=160 MHz cf1=5570 cf2=0
wpa_supplicant_s1g: wlan0: CTRL-EVENT-CHANNEL-SWITCH freq=5500
ht_enabled=1 ch_offset=1 ch_width=160 MHz
cf1=5570 cf2=0
[5598.837043] morse: post_channel_switch — countdown reached 0,
finalizing
STA wpa_cli status post-switch: wpa_state=COMPLETED,
key_mgmt=FT-SAE, freq=5500
STA iw dev wlan0 link: Connected, traffic flowing on freq 5500.
Result: SUCCESS — STA followed the in-band CSA at 160 MHz width.
The kernel-level CSA-follow path WORKS when destination is
mapped into a US-regdom-permitted band.
== Test 4 — 8 MHz CH_28 → 8 MHz CH_44 (repeat of test 1) ==
Same AP command as test 1. AP moved to channel 149 / 5745 MHz /
width 160 successfully.
STA disconnected and reassociated after ~28 s — same outcome as
test 1. NOT intermittent — fully reproducible.
== The deterministic pattern ==
Same chan_switch API, same supplicant, same hardware, same
rel_1_17_8_2026_Mar_24 build. The difference is purely the
destination’s cfg80211-mapped UNII band:
Destination cfg80211-mapped Result
HaLow CH_28 5500 MHz / 160 MHz / UNII-2C FOLLOW ✓
HaLow CH_44 5745 MHz / 160 MHz / UNII-3 REJECT ✗
2 MHz @ 923 MHz 5785 MHz / 40 MHz FOLLOW ✓
Under US regdom, 160 MHz emission is permitted in UNII-2C
(5500-5720) under DFS rules and forbidden in UNII-3 (5745-5825).
The cfg80211 compat shim that presents the 8 MHz S1G block as a
5 GHz 160 MHz channel inherits this regdom check at the
destination side, even though the S1G regdom (which is what
actually applies on the radio) does permit the move.
== Questions ==
-
Is this deterministic destination-band-dependent rejection a
known issue on rel_1_17_8_2026_Mar_24? Has it been addressed
in a newer build? -
Can the cfg80211 compat shim be patched to bypass the 5 GHz
regdom check during a CSA follow when the original PHY is
S1G (i.e. let the S1G regdom govern)? Or alternatively, can
the mapping for HaLow CH_44 avoid landing on a UNII-3 freq? -
Is there a runtime override (morsectrl flag, kernel
parameter, or wpa_supplicant_s1g option) that we can set
on the STA side to disable the 5 GHz regdom check for these
mapped channels? -
If the user-space workaround is the only option for now,
can you confirm which HaLow channels in US are SAFE to use
for in-band CSA without hitting this issue? Our reading of
the US plan is anything mapped under UNII-2C is safe; CH_44
mapped into UNII-3 is not. -
Are there any other UNII bands besides UNII-3 that will
trigger the same rejection (UNII-1 / UNII-4)?
A 60-second sniffer pcap + full kernel logread for any of the
above tests is available on request. The snippets are the load-
bearing lines.
Thanks,
───── APPENDIX A: AP hostapd-phy0-wlan0.conf (passphrases redacted) ─────
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=US
hw_mode=a
channel=28
chanlist=28
op_class=4
s1g_capab=[SHORT-GI-ALL]
s1g_prim_chwidth=1
s1g_prim_1mhz_chan_index=3
ieee80211ah=1
anti_clogging_threshold=99999
interface=wlan0
ctrl_interface=/var/run/hostapd_s1g
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=0
skip_inactivity_poll=0
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
beacon_int=100
wpa_group_rekey=604800
nas_identifier=0cbf74001f05
sae_require_mfp=1
wpa_passphrase=
sae_password=
wpa_psk_file=/var/run/hostapd-wlan0.psk
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=g7-AP-00000001
bridge=br-lan
wds_bridge=
wnm_sleep_mode=1
bss_transition=1
rrm_neighbor_report=1
rrm_beacon_report=1
mobility_domain=a1b2
ft_psk_generate_local=0
ft_over_ds=0
reassociation_deadline=20000
r1_key_holder=0cbf74001f05
r0_key_lifetime=10000
pmk_r1_push=0
r0kh=ff:ff:ff:ff:ff:ff * 80ab93aff49137476a8acededb853f3a
r1kh=00:00:00:00:00:00 00:00:00:00:00:00 80ab93aff49137476a8acededb853f3a
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=SAE FT-SAE
okc=1
ieee80211w=2
group_mgmt_cipher=AES-128-CMAC
wds_sta=1
bssid=0c:bf:74:00:1f:05
sae_pwe=0
dpp_configurator_connectivity=1
raw=0
(TX queue / WMM blocks at defaults — omitted)
───── APPENDIX B: STA full kernel + supplicant log (Test 1, failing) ─────
(captured with CSA-OOB workaround DISABLED so only the in-band CSA
path is exercised; kernel uptime stamps in [seconds])
[4390.369166] kern.info wlan0: deauthenticating from
0c:bf:74:00:1f:05 by local choice
(Reason: 2=PREV_AUTH_NOT_VALID)
daemon.notice wpa_supplicant_s1g: wlan0:
SME: Deauth request to the driver failed
[4414.171472] kern.info wlan0: AP 0c:bf:74:00:1f:05 switches to
unsupported channel (5745.000 MHz, width:5,
CF1/2: 5815.000/0 MHz), disconnecting
daemon.notice wpa_supplicant_s1g: wlan0:
CTRL-EVENT-DISCONNECTED bssid=0c:bf:74:00:1f:05
reason=4 locally_generated=1
daemon.notice wpa_supplicant_s1g: wlan0: Added BSSID
0c:bf:74:00:1f:05 into ignore list, ignoring
for 10 seconds
───── APPENDIX C: STA full kernel + supplicant log (Test 3, succeeding) ─────
(same CSA-OOB-disabled setup; switching back into UNII-2C-mapped
destination — CSA follow works at the kernel level)
[5598.120591] kern.info morse: pre_channel_switch: count=4,
target_freq=5500 MHz, blockTX=0
daemon.notice wpa_supplicant_s1g: wlan0:
CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5500
ht_enabled=1 ch_offset=1 ch_width=160 MHz
cf1=5570 cf2=0
daemon.notice wpa_supplicant_s1g: wlan0:
CTRL-EVENT-CHANNEL-SWITCH freq=5500
ht_enabled=1 ch_offset=1 ch_width=160 MHz
cf1=5570 cf2=0
[5598.837043] kern.info morse: post_channel_switch — countdown
reached 0, finalizing
No disconnect, no reassoc. STA stays on the same BSS, traffic
continues, wpa_state remains COMPLETED, key_mgmt remains FT-SAE.
───── APPENDIX D: AP hostapd log (chan_switch path, all tests) ─────
daemon.info hostapd_s1g: wlan0: IEEE 802.11 CHAN_SWITCH EHT config 0x2
HE config 0x2 VHT config 0x1
daemon.notice hostapd_s1g: hostapd_fill_csa_settings : ECSA info
op_bw=160, prim_bw=1, vht=1, ht=1,
change to oldconfig: ht=1, vht=1
(ECSA IE correctly populated for all 4 tests; the AP-side API works
as documented in your community thread regardless of destination.)