ast STA roaming (802.11r FT) between two HaLow APs — handoff fails: "lands then deauths" within 3s

General
1

Hello Morse Micro Support,

We are seeing slow STA->STA handoffs (~2 seconds) on MM8108-EKH01 and would like to confirm whether 802.11r FT is supported on the current OpenWrt/driver stack, and if so the correct configuration to achieve sub-200 ms cross-channel STA roams.

Setup

  • Hardware: 2× MM8108-EKH01 boards configured as HaLow APs + 1× MM8108-EKH01 board as HaLow STA, all on Raspberry Pi 4

  • Software (from STA g7-sta-00000001):

$ uname -r
5.15.167
$ cat /etc/openwrt_release
DISTRIB_ID=‘OpenWrt’
DISTRIB_RELEASE=‘23.05.5’
DISTRIB_REVISION=‘r0+24325-747fb9b5e1’
DISTRIB_TARGET=‘bcm27xx/bcm2711’
DISTRIB_ARCH=‘aarch64_cortex-a72’
DISTRIB_DESCRIPTION=‘OpenWrt 23.05.5 Morse-2.9.3’
$ wpa_cli_s1g -v
wpa_cli v2.12-morse_micro-rel_1_16_4_2025_Sep_18
$ hostapd_s1g -v
hostapd v2.12-morse_micro-rel_1_16_4_2025_Sep_18

  • Driver: morse_driver from the 2.9.3 release tarball (/usr/sbin daemons dated 2025-Sep-18).

  • Security: WPA3-Personal (SAE), same SSID (g7-AP), same PSK on both APs

  • Channels: AP1 on CH_28 (S1G ch 28, mapped to 5570 MHz cfg80211), AP2 on CH_12 (mapped to 5250 MHz cfg80211) — cross-channel ESS

What we tried (and what failed)

  1. wpa_cli_s1g -i wlan0 roam <target_bssid> — the link lands on the target AP momentarily (wlan0: associated to <new_bssid> in dmesg), but within ~3 seconds the AP sends a deauth and the STA falls back. Pattern repeats regardless of signal strength (tested at −40 / −50 dBm to both APs).

  2. wpa_cli_s1g -i wlan0 reassociate after set_network 0 bssid <target> + set_network 0 scan_freq <freq> — works reliably but performs a full WPA3-SAE handshake. End-to-end handoff takes ~2 s.

  3. PMKSA / OKC caching via pmksa_caching=1 okc=1 in the supplicant network block — set but observed minimal effect; the full handshake still seems to happen on every roam (likely because we are roaming between two different BSSIDs in different cells — we need OKC support on both APs and a shared PMK-R1 distribution mechanism, which we have not configured).

Questions

  1. Is 802.11r FT supported on MM8108 with morse_driver + hostapd_s1g/wpa_supplicant_s1g 2.12-morse-rel_1_16_4_2025_Sep_18 in the 2.9.3 OpenWrt release? If supported in a newer release (driver 1.17.x?), which one?

  2. If FT is supported, what is the correct hostapd_s1g configuration to enable it across two HaLow APs? Specifically:

    • mobility_domain=XXXX requirements

    • r0_key_holder / r1_key_holder MAC selection

    • ft_psk_generate_local=1 vs static r0kh/r1kh entries

    • PMK-R1 distribution requirement — do both APs need to be on the same wired LAN, or does FT-over-DS work over the air?

  3. What key_mgmt= should the STA supplicant advertise? FT-SAE only, or FT-SAE SAE for fallback?

  4. Is the “lands then deauths within ~3 s” symptom a known issue on a specific firmware/driver version? Is there a known fix or workaround?

  5. If FT is not supported on 2.9.3, what is the recommended fast-roam mechanism for sub-200 ms STA handoffs between two HaLow APs in an ESS on this platform? (Plain PMKSA + OKC, or 802.11v BTM?)

  6. Are there any driver/firmware logs we should capture (e.g., dmesg | grep morse, wpa_supplicant -dd, or a debug-enabled morse_driver build) that would help diagnose the wpa_cli roam failure mode?

Our current fallback (full reassociate + 2 s settle to detect the deauth) gives ~2 s total handoff. We need to reduce this significantly for streaming use cases that cannot tolerate 2 s gaps.

Best regards,