Identical MM8108 EKH01 hardware, identical kernel (5.15.189) + driver (kmod-morse 5.15.189+rel_1_17_8_2026_Mar_24-1), identical FT-SAE configuration.
- Single wifi-iface
mode=sta→ associates to upstream AP successfully (-49 dBm, ~500 ms handshake, stable for hours). - Two wifi-iface on the same radio (
mode=sta+mode=ap, our “REPEATER”) → supplicant stuck inwpa_state=SCANNING,morse_cmd_set_channelfails withrc -32768, andmorse_mac_config_ps [vif:1]fails withret:-19.
Same SSID, same PSK, same sae_pwe=0, same ieee80211w=2, same mobility_domain=a1b2, same r0kh/r1kh. The only differentiator is multi-vif vs single-vif on the same radio.
This configuration used to work on the previous build (5.15.167 + rel_1_16_4_2025_Sep_18). After the OpenWrt 23.05.5 → 23.05.6 upgrade pulled in rel_1_17_8, REPEATER stopped associating.
Question
- Is the multi-vif (
mode=sta + mode=apon a single radio) regression onrel_1_17_8a known issue? - Is there a recommended
uci/ hostapd / wpa_supplicant configuration we should add for multi-vif onrel_1_17_8? - Is there a fixed driver release we can pull from your OpenWrt feed, or a build flag we should change?
Hardware & Software
- Board: MM8108 EKH01, aarch64.
- OS: OpenWrt 23.05.6 (
r0+24540-2916bcda3f). - Kernel: 5.15.189.
- Driver:
kmod-morse 5.15.189+rel_1_17_8_2026_Mar_24-1. - hostapd / wpa_supplicant: vendor-built
hostapd_s1g/wpa_supplicant_s1g, both 2.12-morse-rel_1_17_8. bcf: stock EKH01 (no_extblob; EKH01 vs HL2 distinction).- Radio: 8 MHz HaLow, US country,
CH_12(908 MHz HaLow / 5250 MHz mapped). - Auth: WPA3-Personal SAE + 802.11r FT-SAE (per your 2026-06 recipe),
sae_pwe=0,ieee80211w=2,mobility_domain=a1b2.
Direct comparison — two identical EKH01 boards, identical driver
Board A (.203) - mode = single wifi-iface mode=sta:
- kmod-morse 5.15.189+rel_1_17_8_2026_Mar_24-1
- Wireless config: ONE wifi-iface, mode=sta, encryption=sae,
key_mgmt=SAE (FT-SAE advertised by AP, supplicant falls back to SAE)
- Result: associated to upstream AP at -49 dBm, sae handshake ~500 ms,
link stable indefinitely.
Board B (.201) - mode = multi-vif (REPEATER) on same radio:
- kmod-morse 5.15.189+rel_1_17_8_2026_Mar_24-1 (IDENTICAL to .203)
- Wireless config: TWO wifi-iface entries on radio0:
* repeater_uplink (mode=sta, wds=1)
* repeater_downlink (mode=ap, wds=1, ieee80211r=1 ...)
- Result: supplicant stuck in wpa_state=SCANNING; auth/assoc never
initiated; dmesg shows driver-level command failures.
Failure-mode logs from Board B (.201, REPEATER)
dmesg
[ 3041.370077] morse_sdio mmc1:0001:2: Command morse_cmd_set_channel 01:710 failed with rc -32768 (0xffff8000)
[ 3041.379835] morse_sdio mmc1:0001:2: morse_mac_set_channel (morse_mac_change_channel): morse_cmd_set_channel() failed, ret -32768
[ 3060.306348] morse_sdio mmc1:0001:2: Command morse_cmd_set_ps 16:580 failed with rc -19 (0xffffffed)
[ 3060.315432] morse_sdio mmc1:0001:2: morse_mac_config_ps: [vif:1] failed (ret:-19)
[ 3165.012063] morse_sdio mmc1:0001:2: Command morse_cmd_set_ps 16:570 failed with rc -19 (0xffffffed)
[ 3165.021118] morse_sdio mmc1:0001:2: morse_mac_config_ps: [vif:1] failed (ret:-19)
-32768 (0xffff8000) from morse_cmd_set_channel, plus -19 = -ENODEV from morse_cmd_set_ps against [vif:1], only ever fire when the second virtual interface on the same radio is being brought up. Single-iface configurations never reach this code path.
logread (supplicant)
wpa_supplicant_s1g[19538]: wlan0: Failed to initiate sched scan
wpa_supplicant_s1g[19538]: wlan0: Reject scan trigger since one is already pending
wpa_supplicant_s1g[19538]: wlan0: Failed to initiate AP scan
wpa_supplicant_s1g[19538]: wlan0: Reject scan trigger since one is already pending
# wpa_cli wlan0 status returns indefinitely:
wpa_state=SCANNING
Hostapd config (downlink iface) — generated by netifd
ssid=g7-AP
channel=12
wpa=2
wpa_key_mgmt=SAE FT-SAE
ieee80211w=2
sae_pwe=0
mobility_domain=a1b2
ft_psk_generate_local=0
reassociation_deadline=20000
r1_key_holder=0cbf74001f05
nas_identifier=0cbf74001f05
r0_key_lifetime=10000
pmk_r1_push=0
r0kh=ff:ff:ff:ff:ff:ff * a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
r1kh=00:00:00:00:00:00 00:00:00:00:00:00 a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
Supplicant config (uplink STA iface, same wireless block)
country=US
ctrl_interface=/var/run/wpa_supplicant_s1g
sae_pwe=0
network={
scan_ssid=1
ssid="g7-AP"
key_mgmt=SAE
sae_password="...32-char PSK..."
pairwise=CCMP
proto=RSN
ieee80211w=2
bssid=50:2e:91:d2:ce:54
}
uci wireless — multi-vif REPEATER
wireless.radio0=wifi-device
type='morse'
band='s1g'
hwmode='11ah'
country='US'
channel='12'
wireless.repeater_uplink=wifi-iface
device='radio0'
mode='sta'
network='lan'
wds='1'
ssid='g7-AP'
encryption='sae'
key='...'
bssid='50:2e:91:d2:ce:54'
wireless.repeater_downlink=wifi-iface
device='radio0'
mode='ap'
network='lan'
wds='1'
ssid='g7-AP'
encryption='sae'
key='...'
ieee80211r='1'
mobility_domain='a1b2'
sae_pwe='0'
ft_psk_generate_local='0'
r1_key_holder='0cbf74001f05'
nasid='0cbf74001f05'
r0_key_lifetime='10000'
pmk_r1_push='0'
list r0kh 'ff:ff:ff:ff:ff:ff,*,a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6'
list r1kh '00:00:00:00:00:00,00:00:00:00:00:00,a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6'
Success-case logs from Board A (.203, STA single-iface)
iw dev wlan0 link
Connected to 50:2e:91:d2:c6:59 (on wlan0)
SSID: g7-AP
freq: 5560
signal: -49 dBm
rx bitrate: 702.0 MBit/s VHT-MCS 8 160MHz VHT-NSS 1
tx bitrate: 866.7 MBit/s VHT-MCS 9 160MHz short GI VHT-NSS 1
bss flags: short-slot-time
dtim period: 2
beacon int: 100
Supplicant config (.203)
country=US
sae_pwe=0
network={
scan_ssid=1
ssid="g7-AP"
key_mgmt=SAE FT-SAE ← FT-SAE NEGOTIATED (because single iface
network block also has mobility_domain
pre-set; netifd writes both key_mgmt
options when ieee80211r is implied)
sae_password="...same PSK..."
ieee80211w=2
}
What we have tried
- Same FT-SAE recipe (your 2026-06 reply) on both boards — verified in the auto-generated hostapd / supplicant configs.
- Both
mobility_domain=a1b2,ieee80211w=2,sae_pwe=0,ft_psk_generate_local=0— propagating into the actual on-disk configs (not justuci). r0kh/r1khwildcard entries with comma-separated field format so netifd correctly emits them asr0kh=ff:ff:ff:ff:ff:ff * <key>.- Identical PSK across all APs and STAs.
wifi down+wifi upto force a full re-init — same failure pattern reproduces every time.
What changed since this worked
- OS upgrade pulled
OpenWrt 23.05.6andkmod-morse rel_1_17_8_2026_Mar_24in place of the previously-workingOpenWrt 23.05.5/kmod-morse rel_1_16_4_2025_Sep_18. - Configuration delta is minimal (we already had multi-vif REPEATER working before the upgrade).
What we need from you
- Confirmation whether multi-vif (
mode=sta + mode=apon the same radio) is still a supported configuration on the current driver/firmware build. - If yes — the missing config option / build flag / netlink call we are missing on
rel_1_17_8that was implicit onrel_1_16_4. - If no — what is the recommended path for STA+AP coexistence on a single HaLow radio going forward (separate
wlan0.staNvirtual interface? A differentbcf?morse_clicommand we should issue before bringing the second VIF up?).
I’d love to capture a Sniffer trace to compare working vs broken associate sequences but the STA never gets past wpa_state=SCANNING, so there’s nothing on the air from the STA side to capture — the failure is in the driver→firmware command (morse_cmd_set_channel) before any frame is transmitted. Happy to capture a sniffer trace from an external HaLow monitor if it would still help.
Thanks,
Best regards, Asaf Tvito Senior RT Embedded Software Engineer Mobile: +972-52-2564597 Email: Asaf.Tvito@RTDevSoft.com
STA uplink alone — works perfectly (3 s association, stable).
The remaining failure is repeatable and reproducible: