# HaLow REPEATER (MM8108 rel\_1\_17\_8) — two open issues: multi-VIF bring-up cycle + STA not following ECSA **URL:** \ **Category:** General\ **Created:** [July 13, 2026, 11:41am UTC](https://community.morsemicro.com/t/halow-repeater-mm8108-rel-1-17-8-two-open-issues-multi-vif-bring-up-cycle-sta-not-following-ecsa/1819 "2026-07-13T11:41:04Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Asaftv](https://avatars.discourse-cdn.com/v4/letter/a/8491ac/32.png) [@Asaftv](https://community.morsemicro.com/u/Asaftv)\ **Post date:** [July 13, 2026, 11:41am UTC](https://community.morsemicro.com/t/halow-repeater-mm8108-rel-1-17-8-two-open-issues-multi-vif-bring-up-cycle-sta-not-following-ecsa/1819/1 "2026-07-13T11:41:04Z")
Subject: HaLow REPEATER (MM8108 rel\_1\_17\_8) — two open issues: multi-VIF bring-up cycle + STA not following ECSA Hi Morse Micro Support, Opening a fresh case for two related but distinct issues we’re seeing on the EKH01 REPEATER setup. Both are reproducible on plain uci (no Python state machine required). mm\_dumps for both scenarios attached at the bottom. # ================================================================= ENVIRONMENT Firmware : rel\_1\_17\_8\_2026\_Mar\_24 Morse Driver : 0-rel\_1\_17\_8\_2026\_Mar\_24 Dot11ah Driver : 0-rel\_1\_17\_8\_2026\_Mar\_24 morse\_cli : rel\_1\_17\_8\_2026\_Mar\_24 Morsectrl : rel\_1\_17\_8\_2026\_Mar\_24 Hostapd : 2.12-morse\_micro-rel\_1\_17\_8\_2026\_Mar\_24 WPA\_Supplicant : 2.12-morse\_micro-rel\_1\_17\_8\_2026\_Mar\_24 IW : 5.19 OpenWRT : Morse-2.11.12 Chip : MM8108B2 TOPOLOGY .200 — HALOWLINK2 AP (g7-AP, CH\_28, 8 MHz BW, SAE) .202 — HALOWLINK2 AP (g7-AP, CH\_28, 8 MHz BW, SAE) .203 — EKH01 REPEATER (multi-VIF: STA on wlan0 backhaul + AP on wlan1 fronthaul, same radio, both g7-AP) # ================================================================= ISSUE #1 — REPEATER multi-VIF: STA drops within ~30 ms of AP enable, infinite cycle REPRODUCER Module reloaded with PS knobs off (this alone eliminates the `morse_cmd_set_ps [vif:1] failed -19` cascade, but the failure below still stays): rmmod morse insmod /lib/modules/5.15.167/morse.ko reattach\_hw=0 enable\_sgi\_rc=1 enable\_ps=0 enable\_dynamic\_ps\_offload=0 enable\_pre\_assoc\_ps=0 country=US /etc/config/wireless (minimum needed): wireless.radio0.type=‘morse’ wireless.radio0.band=‘s1g’ wireless.radio0.hwmode=‘11ah’ wireless.radio0.country=‘US’ wireless.radio0.channel=‘28’ wireless.radio0.htmode=‘HE8’ wireless.radio0.s1g\_chanbw=‘8’ wireless.radio0.op\_class=‘4’ wireless.repeater\_uplink=wifi-iface wireless.repeater\_uplink.device=‘radio0’ wireless.repeater\_uplink.mode=‘sta’ wireless.repeater\_uplink.network=‘ahwlan’ wireless.repeater\_uplink.ssid=‘g7-AP’ wireless.repeater\_uplink.encryption=‘sae’ wireless.repeater\_uplink.sae\_pwe=‘2’ wireless.repeater\_uplink.bssid=‘’ wireless.repeater\_downlink=wifi-iface wireless.repeater\_downlink.device=‘radio0’ wireless.repeater\_downlink.mode=‘ap’ wireless.repeater\_downlink.network=‘lan’ wireless.repeater\_downlink.ssid=‘g7-AP’ wireless.repeater\_downlink.encryption=‘sae’ wireless.repeater\_downlink.sae\_pwe=‘2’ wireless.repeater\_downlink.disabled=‘1’ ← starts disabled Steps: 1. wifi up → only STA iface comes up (AP disabled) 2. STA associates to upstream cleanly (~3 s) `iw dev wlan0 link` → Connected to @ 5560 3. uci set wireless.repeater\_downlink.disabled=0 uci commit wireless wifi reload OBSERVED Within ~30 ms of `wifi reload` returning: • `iw dev` shows BOTH ifaces (wlan0 managed + wlan1 AP) but the STA association is gone. • wpa\_supplicant\_s1g (restarted by netifd during reload) retries auth in a loop, all timeouts: wlan1: authenticate with wlan1: send auth to (try 1/3) wlan1: send auth to (try 2/3) wlan1: send auth to (try 3/3) wlan1: authentication with timed out The AP-side hostapd\_s1g never receives these auth frames (nothing in its log for this STA MAC during the window). • Symmetric on the downlink AP: clients trying to associate to the REPEATER’s AP get wlan0: STA IEEE 802.11: did not acknowledge authentication response The AP sends the response; no ACK ever comes back. • `iw dev wlan_ap info` shows type AP but no ssid/channel — beacon parameters never got applied. WORKAROUNDS WE’VE TRIED (none work) • Bypass `wifi reload` — add the AP iface manually with `iw phy phyN interface add wlan_ap type __ap` and start hostapd\_s1g on a hand-built conf. → hostapd starts, then fails: nl80211: kernel reports: Match already configured Failed to set beacon parameters • start\_disabled=1 on the downlink wifi-iface, enable it after STA assoc via `hostapd_cli_s1g -i wlan0 enable`. → driver still rejects STA auth once the second vif exists. QUESTIONS ON ISSUE #1 1. Is multi-VIF STA+AP on a single radio supposed to work in the plain “morse” backend without prplmesh? Reading /lib/netifd/wireless/morse.sh, `for_each_interface "ap sta adhoc mesh none monitor"` processes AP first; I don’t see explicit STA-wait logic. Is that intentional, and orchestrated by the prplmesh agent when present? 2. Are there other module parameters or uci options to try? (Tested: enable\_ps=0, enable\_dynamic\_ps\_offload=0, enable\_pre\_assoc\_ps=0, start\_disabled=1, sae\_pwe=2.) 3. Do you have a known-good /etc/config/wireless example for concurrent STA+AP on MM8108 we could diff against ours? # ================================================================= ISSUE #2 — STA on EKH01 does NOT follow hostapd\_cli\_s1g chan\_switch (ECSA) — disconnects instead Independent of the REPEATER — this reproduces with a plain single-VIF STA on the same radio. REPRODUCER • AP : HALOWLINK2 on CH\_28, g7-AP, SAE. • STA : EKH01, single-VIF mode=sta, ssid=g7-AP, SAE, associated to the AP. Verified with `iw dev wlan0 link` → Connected @ 5560. Then, on the AP: hostapd\_cli\_s1g -i wlan0 chan\_switch 10 905000 ‘prim\_bandwidth=2’ ‘sec\_channel\_offset=1’ ‘center\_freq1=908000’ ‘bandwidth=8’ Goal: in-band CSA from CH\_28 (5560 MHz) to CH\_12 (5180/5250 MHz), 8 MHz BW, 2 MHz primary, 10-beacon countdown. AP SIDE — DID THE RIGHT THING hostapd\_s1g: CHAN\_SWITCH EHT config 0x2 HE config 0x2 VHT config 0x1 hostapd\_s1g: hostapd\_fill\_csa\_settings : ECSA info op\_bw=160, prim\_bw=2, vht=1, ht=1 hostapd\_s1g: CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5180 ht\_enabled=1 ch\_offset=1 ch\_width=160 MHz cf1=5250 cf2=0 hostapd\_s1g: AP-CSA-FINISHED s1g\_freq=908000 dfs=0 ECSA IE looks valid (op\_bw=160 mapped, prim\_bw=2 — non-zero). AP moved cleanly from CH\_28 to CH\_12. STA SIDE — DID NOT FOLLOW Immediately after the CSA: (AP-side) hostapd\_s1g: AP-STA-DISCONNECTED (AP-side) hostapd\_s1g: WDS-STA-INTERFACE-REMOVED ifname=wlan0.sta1 The STA drops the association within ~4 s of the announcement, enters link-loss debounce, runs a full scan, and reassociates — either to the same AP on the new channel (after ~30 s), or to a DIFFERENT AP that stayed on the original channel if one is in range. Same outage cost as if the AP had been brought down entirely. Reproducible 100% of the time. We repeated it across two different HALOWLINK2 APs, in each direction (CH\_28→CH\_12 and CH\_12→CH\_28), same result. QUESTIONS ON ISSUE #2 1. Is there a known issue with morse.ko on the STA side ignoring or mishandling the ECSA IE on rel\_1\_17\_8? 2. Is there a wpa\_supplicant\_s1g option, iw command, or module parameter to enable so the STA follows the announcement? 3. Are the ECSA values we emit (op\_bw=160 mapped, prim\_bw=2) the right shape for the STA driver to act on, or is the 5 GHz mapped op\_bw=160 itself the problem? # ================================================================= ATTACHMENTS Issue #1 (REPEATER multi-VIF failure cycle): mm\_dumps\_203\_REPEATER\_2026-06-19.tar.gz ← REPEATER (STA+AP) mm\_dumps\_202\_AP\_2026-06-19.tar.gz ← upstream AP mm\_dumps\_201\_AP\_2026-06-19.tar.gz ← second AP for context Issue #2 (STA not following ECSA chan\_switch): mm\_dumps\_203\_REPEATER\_csa-test.tar.gz ← STA side (disconnect + reassoc) mm\_dumps\_202\_AP\_csa-test.tar.gz ← AP side (ECSA emit + finished) All dumps captured without rebooting after the failure event, default logging settings. Happy to provide packet captures, kernel debug traces, or run additional diagnostics. [mm\_dumps\_201\_AP\_2026-06-19.tar.gz](https://community.morsemicro.com/uploads/short-url/g3shCKSepMdRHFsJQ1HgrsTkOq6.gz) (1.4 MB) [versions\_201.txt](https://community.morsemicro.com/uploads/short-url/1Wcs7xaQl8NOiFR1TSV8hvtcTYL.txt) (522 Bytes) [mm\_dumps\_203\_REPEATER\_csa-test.tar.gz](https://community.morsemicro.com/uploads/short-url/aYY3qU073udnOH33URTULSnAk8G.gz) (1.4 MB) [mm\_dumps\_203\_REPEATER\_channel-change.tar.gz](https://community.morsemicro.com/uploads/short-url/bLdQudklx1LcGYRUS5oIWEVNYEW.gz) (1.4 MB) [mm\_dumps\_203\_REPEATER\_2026-06-19.tar.gz](https://community.morsemicro.com/uploads/short-url/cFvkb9wRqBeeamPBVMg3JJcQ9sS.gz) (1.4 MB) [mm\_dumps\_202\_AP\_csa-test.tar.gz](https://community.morsemicro.com/uploads/short-url/9w4gFC2uaWMTqzmc7YptnRLbIFr.gz) (289.7 KB) [mm\_dumps\_202\_AP\_channel-change.tar.gz](https://community.morsemicro.com/uploads/short-url/uL9AVCFPlxHFe5KiNqpXIn94yZz.gz) (293.2 KB) [mm\_dumps\_202\_AP\_2026-06-19.tar.gz](https://community.morsemicro.com/uploads/short-url/8gpzsEYvmSEk87ZRzHeOAiTIlxC.gz) (297.5 KB) Thanks, Asaf [asaf.tvito@rtdevsoft.com](mailto:asaf.tvito@rtdevsoft.com) [asaf.tvito@rtdevsoft.com](mailto:asaf.tvito@rtdevsoft.com) ---
**Author:** ![ajudge](https://avatars.discourse-cdn.com/v4/letter/a/c2a13f/32.png) [@ajudge](https://community.morsemicro.com/u/ajudge)\ **Post date:** [July 14, 2026, 7:55am UTC](https://community.morsemicro.com/t/halow-repeater-mm8108-rel-1-17-8-two-open-issues-multi-vif-bring-up-cycle-sta-not-following-ecsa/1819/2 "2026-07-14T07:55:11Z")
Hi @Asaftv For distinct issues I would have preferred separate threads, especially considering one of these is a duplicate. So that we don’t get confused and lose the detail like last time (discussion about CSA issues in a thread originally about the repeater). **I will focus on Issue #1 first**. A dual interface is known to work. However, we have no mechanism on our devices for which a station interface will change the channel of a AP VIF on the same radio. That is, the AP VIF is dictating your channel configuration, and your station interface can not lock to the upstream APs channel. The following is a snippet of my own configuration below, which is functioning. ```auto config wifi-device 'radio2' option type 'morse' option path 'platform/1e130000.mmc/mmc_host/mmc0/mmc0:0001/mmc0:0001:2' option band 's1g' option hwmode '11ah' option reconf '0' option bcf 'bcf_mm_hl2_ext.bin' option country 'AU' option channel '32' option s1g_chzn '80211_2020' config wifi-iface 'default_radio2' option mode 'sta' option device 'radio2' option network 'wan' option encryption 'sae' option key 'password1' option wds '1' option ssid 'halowlink1' config wifi-iface 'wifinet1_radio2' option device 'radio2' option encryption 'sae' option ssid 'halowlink2' option key 'password2' option network 'lan' option mode 'ap' option wds '1' ``` For this to work out of the box the channel configuration of the downstream AP (in my example, halowlink2) must much the channelisation of the upstream AP (in my example, halowlink1). No additional parameters outside of uci are required. If you’re wanting to react and follow the upstream APs channel, you will need to bypass UCI and start the AP dynamically. ---
**Author:** ![Asaftv](https://avatars.discourse-cdn.com/v4/letter/a/8491ac/32.png) [@Asaftv](https://community.morsemicro.com/u/Asaftv)\ **Post date:** [July 14, 2026, 10:10am UTC](https://community.morsemicro.com/t/halow-repeater-mm8108-rel-1-17-8-two-open-issues-multi-vif-bring-up-cycle-sta-not-following-ecsa/1819/3 "2026-07-14T10:10:03Z")
Thanks @ajudge. Just to clarify — Issue #1 (the config you addressed) is not actually our problem. We already run exactly the config you posted: a single `morse` radio with two VIFs (`sta` uplink + `ap` downlink), both `wds=1`, both statically set to the **same** channel/channelisation as the upstream AP. That part works. We are not trying to have the STA VIF dictate the AP VIF’s channel. The real issue is **downstream channel-switch propagation (AP → STA)**, not upstream control (STA → AP). Concretely: 1. The upstream/root AP changes channel (CSA / channel switch). 2. The repeater’s **uplink STA follows the CSA correctly** and re-locks on the new channel — so CSA _reception_ on the S1G STA path clearly works. 3. But a **STA associated to the repeater’s own downlink AP does not follow the switch**. It never acts on a channel-switch announcement — it simply drops the link and only recovers via a full (slow) re-association (~3–10 s), instead of a fast in-place channel follow. We traced the cause: when `hostapd_s1g` performs the channel switch (`chan_switch`), the CSA information element it emits is malformed — we see `op_bw=0, prim_bw=0, ht=0, vht=0` in the announcement (from `logread`). Because the announced bandwidth/operating parameters are zeroed, downstream S1G STAs appear to ignore the CSA IE and never perform the in-band channel follow, so they fall back to a disconnect + rescan + reassociation. So the question for Issue #2 is specifically: **is the AP-side CSA IE (**` **hostapd_fill_csa_settings** ` **/ the S1G CSA path) expected to carry valid** ` **op_bw** ` **/** ` **prim_bw** ` **, and is there a fix or a supported way to make associated STAs follow the AP’s channel switch in-band on rel\_1\_17\_8?** Right now every AP-initiated channel move causes all leaf STAs to drop rather than follow. Happy to move this to its own thread as you suggested — this is the “STA not following (E)CSA” issue, separate from the multi-VIF bring-up one. I can attach `logread` captures of the malformed CSA IE and the STA-side drop. ---
**Author:** ![ajudge](https://avatars.discourse-cdn.com/v4/letter/a/c2a13f/32.png) [@ajudge](https://community.morsemicro.com/u/ajudge)\ **Post date:** [July 14, 2026, 1:43pm UTC](https://community.morsemicro.com/t/halow-repeater-mm8108-rel-1-17-8-two-open-issues-multi-vif-bring-up-cycle-sta-not-following-ecsa/1819/4 "2026-07-14T13:43:46Z")
@Asaftv Can I have a human in these threads please. Your bot is confusing, now claiming one of the “two related but distinct issues” is not an issue at all? Secondly, I’m confused by issue #2. Your bot is claiming > STA on EKH01 does NOT follow hostapd\_cli\_s1g chan\_switch (ECSA) — disconnects instead Independent of the REPEATER — this reproduces with a plain single-VIF STA on the same radio. However, the mm\_dumps it is pointing to is a **multi-vif configuration**. Taking it back to basics. Running the exact chan\_switch command you have used with a single-vif sta, the station follows the ecsa as expected. ```auto hostapd_cli_s1g -i wlan0 chan_switch 10 905000 prim_bandwidth=2 sec_channel_offset=1 center_freq1=908000 bandwidth=8 ``` ```auto Tue Jul 14 10:17:37 2026 daemon.notice wpa_supplicant_s1g[5992]: wlh0: CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5180 ht_enabled=1 ch_offset=1 ch_width=160 MHz cf1=5250 cf2=0 Tue Jul 14 10:17:39 2026 daemon.notice wpa_supplicant_s1g[5992]: wlh0: CTRL-EVENT-CHANNEL-SWITCH freq=5180 ht_enabled=1 ch_offset=1 ch_width=160 MHz cf1=5250 cf2=0 ``` So to answer your questions on issue #2: > [@Asaftv](#): > > 1. Is there a known issue with morse.ko on the STA side > ignoring or mishandling the ECSA IE on rel\_1\_17\_8? No. > [@Asaftv](#): > > 1. Is there a wpa\_supplicant\_s1g option, iw command, or > module parameter to enable so the STA follows the > announcement? No > [@Asaftv](#): > > 1. Are the ECSA values we emit (op\_bw=160 mapped, prim\_bw=2) > the right shape for the STA driver to act on, or is the > 5 GHz mapped op\_bw=160 itself the problem? The 5GHz mapping is not the issue here. The issue is that the station interface can not switch because it has an AP interface configured on channel 28. As per the issue with the repeater, **we currently have no mechanism on our devices for which a station interface will change the channel of a AP VIF on the same radio.** You **might** be able to catch `CTRL-EVENT-STARTED-CHANNEL-SWITCH` on your wpa\_supplicant control socket and trigger a chan\_switch on your repeaters hostap - so it can send an ECSA out to it’s associated stations. I doubt this will work though, the timing will be challenging to coordinate. This is also not something we have attempted, so it is strictly unsupported. ---
**Author:** ![Asaftv](https://avatars.discourse-cdn.com/v4/letter/a/8491ac/32.png) [@Asaftv](https://community.morsemicro.com/u/Asaftv)\ **Post date:** [July 14, 2026, 2:08pm UTC](https://community.morsemicro.com/t/halow-repeater-mm8108-rel-1-17-8-two-open-issues-multi-vif-bring-up-cycle-sta-not-following-ecsa/1819/5 "2026-07-14T14:08:18Z")
Hi, **The Issue:** When a **STA** is connected to a **Repeater** , and the **Repeater** is connected to the **Root AP** : 1. I change the channel on the **Root AP**. 2. The **Root AP** successfully sends an ECSA (Channel Switch Announcement) to the **Repeater**. 3. The **Repeater’s STA interface** successfully switches to the new channel. 4. **The Problem:** The **Repeater’s AP interface** does _not_ transmit an ECSA to the **Client STA** connected to it. 5. As a result, the **Client STA** is left behind on the old channel, loses connection, and disconnects. In short: The Repeater successfully follows the Root AP to the new channel, but it fails to inform its own connected clients about the channel switch before it moves. ---
**Author:** ![ajudge](https://avatars.discourse-cdn.com/v4/letter/a/c2a13f/32.png) [@ajudge](https://community.morsemicro.com/u/ajudge)\ **Post date:** [July 14, 2026, 3:11pm UTC](https://community.morsemicro.com/t/halow-repeater-mm8108-rel-1-17-8-two-open-issues-multi-vif-bring-up-cycle-sta-not-following-ecsa/1819/6 "2026-07-14T15:11:14Z")
The issue is that the station interface can not switch because it has an AP interface configured on channel 28. As per the issue with the repeater, **we currently have no mechanism on our devices for which a station interface will change the channel of a AP VIF on the same radio.** You **might** be able to catch `CTRL-EVENT-STARTED-CHANNEL-SWITCH` on your wpa\_supplicant control socket and trigger a chan\_switch on your repeaters hostap - so it can send an ECSA out to it’s associated stations. I doubt this will work though, the timing will be challenging to coordinate. This is also not something we have attempted, so it is strictly unsupported. ---
**Author:** ![Asaftv](https://avatars.discourse-cdn.com/v4/letter/a/8491ac/32.png) [@Asaftv](https://community.morsemicro.com/u/Asaftv)\ **Post date:** [July 14, 2026, 4:17pm UTC](https://community.morsemicro.com/t/halow-repeater-mm8108-rel-1-17-8-two-open-issues-multi-vif-bring-up-cycle-sta-not-following-ecsa/1819/7 "2026-07-14T16:17:23Z")
Thanks for the clarification. Since automatic channel synchronization is a core requirement for our repeater product, is this feature on your roadmap for future releases? Or will this Multi-VIF scenario remain strictly unsupported for the foreseeable future?"