[4.9.0 beta6] Repeater picks SAE on mixed-mode AP and never falls back to PSK

Router
1

[4.9.0 beta6] MT3000 repeater can't join a WPA2/WPA3 mixed-mode AP — picks SAE, never falls back (regression from 4.8.1)

Summary

On 4.9.0 beta6 the MT3000 in Repeater mode fails to associate with an upstream AP that
advertises WPA2/WPA3 transition mode (sae-mixed in OpenWrt terms — PSK and SAE offered
together). The client picks SAE, fails, and never falls back to WPA2-PSK.

The retry loop has a second, worse effect: every rescan drops the beacon of the router's
own AP, so LAN clients repeatedly lose the MT3000's Wi-Fi. The device is not merely
without an uplink — it becomes unusable as an access point.

This is a regression. The same unit, same upstream AP, same passphrase worked reliably on
4.8.1, including re-association after wifi reload.

Device and firmware

  • Model: GL-MT3000 (Beryl AX)
  • Firmware: 4.9.0 beta6, build 1047
  • Image: mt3000-4.9.0_beta6-1047-0703-1783066682.tar
  • SHA256: 03a9ed1d99ca9728eca6042f06c56cea5df299cd1e168b5f9fb51663bda24a32
  • Built: 2026-07-03 15:24:41
  • Kernel: 5.4.211
  • Base: OpenWrt 21.02-SNAPSHOT
  • Driver: mt_wifi (closed-source branch)
  • Installed: clean flash, "keep settings" unchecked
  • Last known good: 4.8.1 (2025-08-19)

Upstream AP

  • Firmware: OpenWrt 24.10.2
  • Radios: 2.4 GHz ch1 HE20, 5 GHz ch36 HE80
  • Encryption: sae-mixed (WPA2-PSK + WPA3-SAE transition mode) on both radios
  • ocv: 0

Steps to reproduce

  1. Configure any AP in WPA2/WPA3 transition mode (option encryption 'sae-mixed').
  2. Clean-flash a GL-MT3000 with 4.9.0 beta6.
  3. Join that network in Repeater mode with the correct passphrase.
  4. Restart the radios (wifi reload), or reboot, or otherwise force a re-association.

Expected

The client associates, using WPA2-PSK if its SAE path does not succeed — transition mode
exists precisely so that non-SAE-capable clients keep working.

Actual

Association never completes. The client keeps attempting SAE, times out, rescans, and
repeats indefinitely. Measured over one 6.5-minute window:

  • 84 × AP Beacon OFF!!!
  • 7 × association failure
  • 7 × SAE parse error — exactly one per failed association

Log excerpts

Failure cycle, verbatim:

kern.err WiFi@C15L1,sae_parse_commit_element_ecc() 4412: pSaeIns->peer_commit_element is not NULL!
kern.notice 7981@C09L3,sta_mlme_assoc_req_action() 783: ASSOC - Send ASSOC request...
kern.err 7981@C09L1,sta_assoc_timeout() 126: ASSOC - enqueue ASSOC_FSM_ASSOC_TIMEOUT
kern.err 7981@C09L1,sta_mlme_assoc_req_timeout_action() 2969: ASSOC - AssocTimeoutAction
kern.err 7981@C09L1,sta_cntl_assoc_conf() 1638: CNTL - Association fails on BSS #4 Reason(16)
kern.notice 7981@C09L3,sta_send_auth_req() 68: STA Start send Auth req
kern.err 7981@C09L1,sta_send_auth_req() 107: AUTH - Send AUTH request seq#1 (Alg=0)...
kern.err WiFi@C15L1,WPAInsertRsnIePMKID() 2405:  (SAE) including the PMKID.

Reason 16 is a Group Key Handshake timeout.

pSaeIns->peer_commit_element is not NULL! appears once per attempt, which suggests the
SAE instance is not reset between retries — state from the previous attempt is still
attached when the next commit element is parsed.

The client also keeps inserting a cached PMKID on every retry, including after a cold boot.

Where the choice is made — gl-repeater, not the driver

The authentication method is selected in userspace, by gl-repeater itself:

daemon.info gl-repeater[10320]: (repeater.lua:1095) connecting to bss: <SSID> aa:bb:cc:dd:ee:fa 1 sae

The daemon inspects the scan result, sees the transition-mode BSS, decides sae, and hands
that down to the driver. There is no attempt to fall back to PSK after the SAE association
times out — the same sae decision is repeated on every retry, indefinitely.

This also explains why the encryption cannot be overridden from configuration:
setting repeater.@network[0].encryption='psk2' has no effect, because the method is
recomputed from the scan on each attempt rather than read from UCI.

Root cause confirmed by a one-byte experiment

repeater.lua is shipped as Lua 5.4 bytecode, but the constant table around the decision is
readable and unambiguous — the scan field and the mapping sit next to each other:

rsn
auth_suites
SAE                 ->  sae
PSK                 ->  psk2
802.1X/SUITE-B-192  ->  wpa3
802.1X              ->  wpa2
OWE                 ->  owe
connecting to

SAE is checked before PSK, so a BSS advertising both always resolves to sae.

To confirm this is the whole story, the lookup key "SAE" was changed to "XAE" — one
byte, same length, so the bytecode layout is unaffected. The string occurs exactly once in
the file.

Result, against the same transition-mode AP that had failed every previous attempt:

gl-repeater (repeater.lua:1095) connecting to bss: <SSID> aa:bb:cc:dd:ee:fa 1 psk2
### SUCCESS after 16s

Association completes in 16 seconds. Nothing else was changed — same AP, same passphrase,
same firmware, same driver.

This rules the MediaTek driver out entirely: with psk2 it associates without complaint.
The defect is the AKM selection in repeater.lua, and a fallback would fix it.

Collateral damage to the router's own AP:

kern.err 7981@C03L1,ExtEventBeaconLostHandler() 176:   AP Beacon OFF!!!
kern.warn 7981@C01L2,RTMP_COM_IoctlHandle() 1505:  -> CMD_RTPRIV_IOCTL_VIRTUAL_INF_DOWN
kern.notice 7981@C09L3,sync_fsm_reset() 2705: SYNC[apcli0, Band:0]: [IDLE] ====> [INIT]
kern.notice 7981@C09L3,sync_fsm_reset() 2705: SYNC[apclix0, Band:1]: [IDLE] ====> [INIT]

Controlled experiment — the decisive one

A second SSID was added on the same upstream AP, on the same radio, same
channel, with the same passphrase. The only difference was the encryption mode:

  • main SSID, encryption='sae-mixed' — never associates, in every configuration tried
  • test SSID, encryption='psk2' — associates in 16 seconds
### CONNECTED after 16s
default via 192.0.2.1 dev apclix0 proto static src 192.0.2.100 metric 20
apclix0   ESSID: "TestNet-WPA2"
          Access Point: AA:BB:CC:DD:EE:FF
          Mode: Client  Channel: 36 (5.180 GHz) HT Mode: HE80

Ruled out

  • Band selection — tried lock_band=5g, lock_band=2g, and unset. Fails in all three.
  • Fixed BSSID — pinned to the 5 GHz BSS, then to the 2.4 GHz BSS. Fails for both.
  • Forcing WPA2 from config — repeater.@network[0].encryption='psk2' is ignored;
    the daemon still selects sae.
  • Stale in-memory SAE state — full reboot does not help; fails from a cold boot,
    132 error events in the first 3 minutes.
  • Regulatory domain — fails with country=RU (22 channels) and country=US (25 channels).
  • Wrong passphrase — ruled out; length and MD5 compared against the AP's own
    configuration, identical.

The 2.4 GHz run was isolated deliberately: the saved-network list was reduced to the single
target entry and smart_reconnect was set to 0, so the daemon had nothing to fall back to.
It still failed, with the same sae_parse_commit_element_ecc → Reason(16) sequence.

Secondary issue: smart_reconnect silently rewrites the target

With smart_reconnect='1' (the default), a failed association does not surface as a failure.
The daemon switches to a different saved network and overwrites the configured ssid, and
clears bssid and lock_band in /etc/config/repeater.

The user-visible result is "connected", to a network they did not select, with their pinning
silently discarded. During diagnosis this produced a false positive that took a while to spot.
Whatever is decided about the SAE issue, a fallback that rewrites explicit user configuration
without any indication is worth revisiting on its own.

Impact

For a travel router this is severe. WPA2/WPA3 transition mode is becoming the default on
current consumer and hospitality equipment, and the guest cannot reconfigure a hotel AP.
The failure is not a graceful "no uplink" — the repeated rescans take the device's own
2.4 GHz and 5 GHz APs down with them, so every connected client is disrupted as well.

Request

  1. In repeater.lua, fall back to PSK when SAE fails against a transition-mode BSS —
    the AKM is chosen there (line ~1095), so this does not require a driver change.
  2. Honour repeater.@network[].encryption when it is set explicitly, instead of always
    recomputing the method from the scan result.
  3. Reset the SAE instance between association attempts
    (pSaeIns->peer_commit_element), and do not replay a cached PMKID after a failure.
  4. Decouple the rescan path from the local AP beacon, or at least rate-limit it, so a
    failing uplink cannot take down the AP the user is connected to.
  5. Do not let smart_reconnect overwrite an explicitly configured ssid / bssid /
    lock_band; if a fallback happens, report it rather than presenting it as success.

Possibly related: the reported inability of legacy clients to connect to a GL-MT6000
whose own AP is set to WPA2/WPA3 mixed mode. That is the other side of the same link,
and may share a root cause in the transition-mode handling.

2

This cipher can cause quite some issues.

This is the same as wpa2-mixed, the problem lays fully on what the client supports.

With wpa3 (sae) MFP is forced in regards of the wifi standard, but it does not on wpa2 it is optional.

The problem is if a device does not support MFP (802.11w) it cannot connect, there might be also other client side implementation issues.

Best is to use wpa2 and have mfp optional if that can be set with these different vendor flavours (not vanilla OpenWrt).

CCMP AES is still very secure, please do not use gcmp if that is a available option, because gcmp is rare on devices with wpa2, it is a wpa3 feature.

Though gcmp is securer, but alot of devices don't like wpa2+gcmp, but wpa3+gcmp is more logical as this cipher was made for it.

3

Thanks — that points at the right mechanism, and the logs confirm it precisely.

MFP is indeed the issue, but not on the AP side. Immediately before every association attempt the repeater configures PMF as capable but not required, and then goes on to offer SAE:

kern.err 7981@C12L1,Set_ApCliPMFMFPC_Proc() 2003: [PMF]: MFPC=1, MFPR=0, SHA256=0
kern.debug SetApCliEnableByWdev: I/F(apcli0) (enable = 1)
daemon.info gl-repeater[10320]: (repeater.lua:1095) connecting to bss: <SSID> <BSSID> 1 sae

That line appears once per attempt, on both radios, in every run.

WPA3-SAE mandates management frame protection — MFPR must be 1. A transition-mode AP advertises MFP as required for the SAE AKM and optional for PSK. Offering SAE with MFPR=0 is not a valid combination, so the association stalls, and we end up with Reason(16), a Group Key Handshake timeout.

This explains the two observations that otherwise look unrelated:

  • PSK associates against the very same AP, because MFP is legitimately optional there.
  • Forcing the AKM away from SAE fixes it without touching the AP — I patched the "SAE" lookup key in repeater.lua so it can never match; the daemon then emits psk2 and the link comes up in 16 seconds. Same AP, same passphrase, same firmware, same driver.

So the defect is narrower than "no fallback": the client selects an AKM whose mandatory requirement it does not then assert. Two independent fixes would each work — set MFPR=1 when SAE is selected, or fall back to PSK when SAE does not complete.

On the suggestion to configure the AP as WPA2 with optional MFP: that works at home, and I verified it — a second SSID with plain psk2 on the same radio associated immediately. But this is a travel router. The whole point is joining networks I do not administer, and WPA2/WPA3 transition mode is becoming the default on current hospitality and consumer gear. Reconfiguring the AP is not an option in a hotel, so the client is where this has to be fixed.

Worth stressing the collateral damage as well: the retry loop does not fail quietly. Each rescan drops the beacon of the router's own AP — 84 × AP Beacon OFF!!! in one 6.5-minute window — so every connected client keeps losing Wi-Fi. Even if the SAE issue takes time to resolve, decoupling the rescan path from the local AP would make the failure survivable.