HaLow REPEATER (MM8108 rel_1_17_8) — two open issues: multi-VIF bring-up cycle + STA not following ECSA

General
1

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 (1.4 MB)

versions_201.txt (522 Bytes)

mm_dumps_203_REPEATER_csa-test.tar.gz (1.4 MB)

mm_dumps_203_REPEATER_channel-change.tar.gz (1.4 MB)

mm_dumps_203_REPEATER_2026-06-19.tar.gz (1.4 MB)

mm_dumps_202_AP_csa-test.tar.gz (289.7 KB)

mm_dumps_202_AP_channel-change.tar.gz (293.2 KB)

mm_dumps_202_AP_2026-06-19.tar.gz (297.5 KB)

Thanks,
Asaf

asaf.tvito@rtdevsoft.com

asaf.tvito@rtdevsoft.com

2

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.

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.

3

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.
4

@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.

hostapd_cli_s1g -i wlan0 chan_switch 10 905000 prim_bandwidth=2 sec_channel_offset=1 center_freq1=908000 bandwidth=8

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:

No.

No

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.

5

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.

6

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.

7

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?"