BPI-R4 WiFi 7 Manager — LuCI app for MT7996 / MT7988A

woziwrt · May 12, 2026, 2:08pm

BPI-R4 WiFi 7 Manager — LuCI app for MT7996 / MT7988A

After extensive testing on real hardware I'm releasing a LuCI-based WiFi 7 manager for the Banana Pi BPI-R4 (MT7988A SoC, MT7996 tri-band chip). It covers the full range of use cases the hardware supports — AP, MLO, STA, WDS, relayd bridge, repeater — with a clean single-page UI that doesn't require juggling raw UCI or hostapd configs.

The goal was to make everything the MT7996 chip can actually do accessible through a proper interface: Multi-Link Operation across 2 or 3 bands, per-radio TX power management, live client monitoring with WiFi generation badges and per-link MLO data, and diagnostics that show what's actually happening at the driver level.

Requires OpenWrt with MediaTek SDK (MTK SDK)
This package is not compatible with mainline OpenWrt. Interface naming, MLD configuration, and hostapd parameters differ significantly between MTK SDK builds and standard OpenWrt releases. MTK SDK builds for BPI-R4 (standard, PoE, 4 GB, 8 GB) are available via bpi-r4-deploy.

Hardware

Component	Details
Board	Banana Pi BPI-R4, BPI-R4 PoE
SoC	MediaTek MT7988A (Filogic 880)
WiFi chip	MT7996 tri-band (2.4 GHz / 5 GHz / 6 GHz)
WiFi standard	802.11be (WiFi 7), MLO

Installation

luci-app-wifimgr is included by default in all BPI-R4 firmware releases built via bpi-r4-deploy — no extra steps needed after flashing.

For standalone install on an existing firmware:

# Copy APK to router
scp luci-app-wifimgr-1.1.0-r20260511.apk root@192.168.1.1:/tmp/

# Install (no internet required)
ssh root@192.168.1.1 'apk add --allow-untrusted --no-network /tmp/luci-app-wifimgr-*.apk'

Then open LuCI → Network → WiFi Manager.

Download: https://github.com/woziwrt/mt7996-wifi7-manager/releases

Features

Wizards — guided network setup

Wizard	Description
MLO AP	Creates a Multi-Link Operation AP across 2 or 3 bands. Supports 2G+5G, 2G+6G, 5G+6G, or all three simultaneously. Per-link channel and width control. WPA3 enforced.
AP	Creates a standard single-band AP on any radio. Full control over channel, width, encryption, SSID isolation, hidden SSID, client limits. DFS channels supported with CAC progress indication.
Station	Connects to an upstream WiFi network on 2.4G or 5G. MLO STA mode supported (multi-band client connecting to an MLO AP).
WDS / Bridge	Sets up a wireless bridge using 4-address WDS mode or L2 relayd ARP proxy.
Repeater	Creates an uplink STA connection plus a local AP on a separate radio (L3 NAT).
Country	Changes regulatory domain. Requires reboot to apply kernel regulatory database.

Networks tab

Live list of all configured networks with status indicators, band pills, WiFi generation badge, encryption labels, and client counts. Each row expands to show full configuration. Inline edit and remove with wifi reload.

Radios tab

Per-radio configuration (channel, bandwidth, country) and TX power management:

Mode	Description
Regulatory	Country SKU table applied. No manual txpower override.
eFuse max	Driver runs at hardware eFuse maximum. Requires reboot.
Manual	Per-radio dBm cap.

Clients tab

Live client list showing signal (color-coded), WiFi generation badge (WiFi 4/5/6/7), bitrate, and per-link data for MLO clients. Disconnect button.

Diagnostics tab

Firmware version, CPU and WiFi chip temperatures, per-radio channel utilization / noise / TX stats, MLO internals (MLD address, active links, EMLSR/STR status), and log download.

Screenshots

Networks tab

Radios tab

Clients tab

Diagnostics tab

MLO wizard

Station wizard

WDS / Bridge wizard

cookiemonster · May 12, 2026, 6:50pm

Please define the type of MLO so people don't get confused. Also most clients are bugged and can't take advantage of MLMR‑STR:

(https://mrncciew.com/2026/03/05/pixel-8-mlo-emlsr-vs-mlmr-str/)

Including wireshark beacon frames would be helpful to confirm what you have enabled via MTK blobs.

woziwrt · May 12, 2026, 7:40pm

MLO type: confirmed STR from two independent sources

1. hostapd_cli (runtime AP state)

$ hostapd_cli -i ap-mld1 status

ieee80211be=1
num_links=3
ap_mld_type=STR
link_id=0   link_addr=e6:ca:22:dd:93:d2   2.4 GHz  ch 1   40 MHz
partner_link[1]=e2:ca:22:dd:af:d2          5 GHz   ch 52  160 MHz
partner_link[2]=ee:ca:22:dd:cf:d0          6 GHz   ch 37  320 MHz

ap_mld_type=STR — the driver reports it directly. No blob-reading required.

2. Wireshark beacon frame analysis (802.11be EHT Multi-Link element, tag 107)

Captured via monitor interface on the STA router (tcpdump -i mon0 type mgt subtype beacon), decoded with tshark:

Ext Tag: Multi-Link (802.11be D3.0)
    Ext Tag Number: Multi-Link (802.11be D3.0) (107)
    Multi-Link Control: 0x03b0  [Type: Basic]

    Common Info:
        MLD MAC Address: e6:ca:22:dd:90:d2
        EML Capabilities: 0x0001
            EMLSR Support:  TRUE
            EMLMR Support:  FALSE          ← EMLMR not implemented in MTK SDK
        MLD Capabilities: 0x2062
            Maximum Number of Simultaneous Links:          2
            Frequency Separation For STR/AP MLD Type:      0  ← STR (no NSTR constraint)
            TID-To-Link Mapping Negotiation Support:        3  (full)
            Link Reconfiguration Operation Support:      TRUE

Per 802.11be spec: Frequency Separation For STR/AP MLD Type Indication = 0 means STR. A non-zero value would indicate the minimum frequency gap below which NSTR applies — there is no such restriction here.

Summary

Property	Value
MLO type	MLMR-STR (3 independent physical radios, simultaneous TX/RX)
EMLSR	Supported (advertised in beacon)
EMLMR	Not supported in current MediaTek SDK
Max simultaneous links per client	2 (MLD capability field)
Links available	3 (2.4 GHz / 5 GHz / 6 GHz)
Confirmed by	`hostapd_cli ap_mld_type=STR` + beacon EHT Multi-Link element

So you were right to push on this — the hardware is MLMR-STR, but the MediaTek SDK currently caps simultaneous links per client at 2 and doesn't implement EMLMR. That's a firmware constraint, not a hardware one (MT7996 has the radios for it).

As for client-side bugginess — fully agree. In testing, most laptops negotiate single-link even against a 3-link MLD. The manager just sets up the AP correctly; what clients actually use is up to their drivers.

cookiemonster · May 12, 2026, 8:17pm

My quick wireshark on 7996e BT8 using open drivers from whenever this was posted:
(Support for Asus ZenWiFi BT8 Tri-band Wifi7 (Mediatek MT7988) - #527 by cookiemonster)

Ext Tag: Multi-Link (802.11be D3.0)
            Ext Tag length: 15 (Tag len: 16)
            Ext Tag Number: Multi-Link (802.11be D3.0) (107)
            Multi-Link Control: 0x01b0 Basic
                .... .... .... .000 = Type: Basic (0)
                .... .... .... 0... = Reserved: 0x0
                .... .... ...1 .... = Link ID Info Present: True
                .... .... ..1. .... = BSS Parameters Change Count Present: True
                .... .... .0.. .... = Medium Synchronization Delay Info Present: False
                .... .... 1... .... = EML Capabilities Present: True
                .... ...1 .... .... = MLD Capabilities Present: True
                .... ..0. .... .... = AP MLD ID Present: False
                .... .0.. .... .... = Extended MLD Capabilities and Operations Present: False
                0000 0... .... .... = Reserved: 0x00

Extended MLD Capabilities and Operations Present: True?

 MLD Capabilities: 0x2000, Link Reconfiguration Operation Support
                    .... .... .... 0000 = Maximum Number of Simultaneous Links: 0
                    .... .... ...0 .... = SRS Support: False
                    .... .... .00. .... = TID-To-Link Mapping Negotiation Support: 0
                    .... 0000 0... .... = Frequency Separation For STR/AP MLD Type Indication: 0
                    ...0 .... .... .... = AAR Support: False
                    ..1. .... .... .... = Link Reconfiguration Operation Support: True
                    .0.. .... .... .... = Aligned TWT Support: False
                    0... .... .... .... = Reserved: 0x0

Aligned TWT: True? Broken clients with eMLSR will make use of that.

woziwrt · May 12, 2026, 8:27pm

Thanks for the 7996e BT8 beacon capture — very helpful detail.

Quick note: my device uses MT7996 (non-e, BPI-R4), so there may be differences in what the firmware advertises in the EHT Multi-Link element. I'll do a beacon capture on my end to compare.

On the two flags you highlighted:

Extended MLD Capabilities inconsistency (True in beacon body, but Multi-Link Control shows False for the "Extended MLD Capabilities And Operations Present" subfield): this looks like a firmware beacon construction bug — the MTK SDK is including the Extended MLD Capabilities subelement in the beacon but not setting the corresponding presence bit in the Multi-Link Control field. That's not something configurable at the hostapd or UCI level; it would need to be fixed upstream in the SDK.

Aligned TWT: True — you're right to flag this. If the firmware advertises Aligned TWT support but doesn't actually implement synchronized TWT scheduling across links, eMLSR clients that attempt to use it will have a bad time. Again, this is hardcoded in the firmware beacon, not controllable via hostapd config.

Both issues point to the MTK SDK firmware rather than the driver/hostapd layer. I'll check if my MT7996 shows the same in Wireshark and if confirmed on both chips, it's worth opening an issue against the MTK SDK.

Do you see actual client behavior problems (drops, failed association, etc.) with eMLSR devices, or is this purely based on the beacon analysis so far?

EDIT:
Checked on BPI-R4 MT7996 (not 7996e) — beacon capture confirms very similar behavior.

Multi-Link Control: 0x1b0 — identical to your 7996e BT8. Same flags: Link ID Info, BSS Params Change Count, EML Capabilities, MLD Capabilities all present; Extended MLD Caps (bit 10) = False.

MLD Capabilities differ slightly:

Our MT7996: 0x2061 (5 GHz link) / 0x2062 (6 GHz link)
Your 7996e: 0x2000

Both share bit 13 set. The difference is that our values also have bits 0–3 (Max Simultaneous Links = 1 or 2) and bits 5–6 (TID-to-Link Mapping = 3) populated.

EML Capabilities: 0x0001 — only EMLSR Support = True, EMLMR = False. No Aligned TWT flag set in the EML field on our end. Did your 7996e BT8 show a different EML Capabilities value with Aligned TWT set there, or is it in the MLD Capabilities field at a different bit offset than what I'm reading?

Conclusion: the 0x1b0 Multi-Link Control and bit 13 of MLD Caps being set appears to be a fixed MTK SDK firmware default across both MT7996 variants — not something configurable from hostapd or UCI. If the Aligned TWT flag is causing actual eMLSR client issues it would need to be addressed upstream in the SDK. Could you share the raw EML Capabilities hex value from your capture? Would help to confirm if the Aligned TWT bit is there or in a different field.

cookiemonster · May 12, 2026, 9:26pm

BT8 is MT7996 using MT799e driver.

Did very limited MLO testing with eMLSR and found zero issues except harmless log spamming. MT7925 clients. TWT should be working with MTK blobs.

Use this guy's wireshark profile for easier wifi 7 testing:
(https://mrncciew.com/2026/02/26/wi-fi-7-how-to-verify-mlo-multi-link-operation/)
(https://mrncciew.com/2025/09/02/get-rockstarwifi-wireshark-profile/)

woziwrt · May 13, 2026, 6:41am

We went digging into the MTK SDK source after your analysis — here's what we found at the C level.

MLD Capabilities: 0x2000 (BT8 MT7996e) vs 0x2061/0x2062 (our MT7988A)

The assembly happens in hostapd/src/ap/ieee802_11_eht.c, function hostapd_eid_eht_basic_ml_common(). The MTK SDK unconditionally OR-s two bits into MLD Capabilities regardless of what the driver reports:

mld_cap = hapd->iface->mld_mld_capa;  // from nl80211 driver caps
/* clear bits 0-3, then set active_links count */
mld_cap &= ~EHT_ML_MLD_CAPA_MAX_NUM_SIM_LINKS_MASK;
mld_cap |= active_links & EHT_ML_MLD_CAPA_MAX_NUM_SIM_LINKS_MASK;

mld_cap |= EHT_ML_MLD_CAPA_LINK_RECONF_OP_SUPPORT;     // 0x2000, bit 13 — unconditional MTK add
mld_cap |= EHT_ML_MLD_CAPA_TID_TO_LINK_MAP_ALL_TO_ALL; // 0x0020, bit 5 — unconditional MTK add

Breaking down our value (0x2061 for 5G link, 0x2062 for 6G link):

Source	Value	Why
Driver `mld_mld_capa` via nl80211	`0x0062`	`max_simul_links=2` + `TTLM_NEG_SUPP_DIFF=0x0060` (`MT7996_NEG_TTLM_SUPPORT` in `mt7996/init.c`)
MTK hostapd: LINK_RECONF	`+0x2000`	Unconditional MTK patch (bit 13)
MTK hostapd: ALL_TO_ALL	`+0x0020`	Unconditional MTK patch (bit 5, already covered by driver's 0x0060)
active_links per link	`+0x0001` or `+0x0002`	`hostapd_get_active_links(hapd)` varies per link
Total	0x2061 / 0x2062	✓ matches our tcpdump capture

BT8 (0x2000) is running an older MTK SDK that already had LINK_RECONF_OP_SUPPORT but didn't yet add TID_TO_LINK_MAP_ALL_TO_ALL, and its mt76 driver doesn't register TTLM negotiation capability. active_links = 0 there → bits 0-3 = 0.

Extended MLD Capabilities: the inconsistency

This was added in MTK SDK hostapd patch 0237-mtk-hostapd-add-support-for-emlsr-enablement-on-one-link (MeiChia Chiu, Nov 2025). Both the ML Control presence bit (bit 10, BASIC_MULTI_LINK_CTRL_PRES_EXT_MLD_CAP) AND the subelement write are gated by exactly the same condition:

// ML Control bit:
if (!hapd->mld->eml_disable && hapd->mld->emlsr_on_one_link)
    control |= BASIC_MULTI_LINK_CTRL_PRES_EXT_MLD_CAP;

// Common Info subelement:
if (!hapd->mld->eml_disable && hapd->mld->emlsr_on_one_link)
    wpabuf_put_le16(buf, hapd->iface->ext_mld_capa_and_ops);

With emlsr_on_one_link=0 (the default — not set in any shipped hostapd.conf we've seen), neither the ML Control bit nor the subelement is written. So in current builds, ML Control stays at 0x01b0 and there's nothing in the Common Info after MLD Capabilities. The inconsistency you observed on BT8 suggests either an intermediate firmware with a partially applied patch, or Wireshark parsing extra bytes past the MLD Capabilities field (e.g. if common_info_len doesn't match what's actually written).

When emlsr_on_one_link=1 is enabled, the Extended MLD Capabilities subelement value comes from hapd->iface->ext_mld_capa_and_ops, which the mt76 patch (0077-mtk-wifi-mt76-mt7996-add-support-for-emlsr-enablement-on-one-link) populates via the new NL80211_ATTR_EXT_MLD_CAPA_AND_OPS nl80211 attribute:

// mt7996/init.c:
.ext_mld_capa_and_ops = IEEE80211_EHT_ML_EXT_MLD_CAPA_EMLSR_ENA_ON_ONE_LINK  // 0x0040, bit 6

So when enabled, the Extended MLD Caps subelement would contain 0x0040 = "EMLSR Enablement On One Link Support".

Aligned TWT

In our beacons (MLD Capa = 0x2061/0x2062) and BT8 (0x2000) — neither has IEEE80211_MLD_CAP_OP_ALIGNED_TWT_SUPPORT = 0x4000 (bit 14) set. Could the "Aligned TWT = True" you saw be coming from the HE MAC Capabilities element rather than the Multi-Link Common Info? The HE Capabilities element has a separate "Aligned TWT" bit (B23 of MAC HE Capabilities subfield) that's independent of MLD capabilities. Would be useful to see the raw hex bytes around the MLD Capabilities in the pcap to confirm which field Wireshark is reading.

Client-side MLD Capabilities comparison (iPhone 16 vs BPI-R4 STA)

We also captured Association Requests from an iPhone 16 and from a BPI-R4 running as MLO STA (sta-mld0, 3-link) connecting to the same AP. Parsed with the mrncciew.com tools and tshark for cross-check:

Feature	iPhone 16	BPI-R4 STA (sta-mld0)	BPI-R4 AP (beacon)
Primary assoc link	5G (5260 MHz)	6G (6135 MHz)	—
EML Capabilities Present	False	False	True (0x0001 EMLSR Supp)
MLD Capabilities	0x0fe1	0x00e2	0x2061/0x2062
Max Simultaneous Links	1 (2-link MLD)	2 (3-link MLD)	1 or 2
SRS Support	False	False	—
TID-to-Link Neg Support	3 (DIFF)	3 (DIFF)	3 (DIFF)
Frequency Separation STR	31	1	—
AAR Support	False	False	—
Link Reconfiguration	False	False	True (MTK unconditional)
Aligned TWT	False	False	False
Extended MLD Caps Present	False	False	False (opt-in via `emlsr_on_one_link`)
Per-STA Profiles	1 (2.4G, Link-0)	2 (2.4G Link-0 + 5G Link-1)	—

A few things from this:

EML Capabilities Present = False for both STAs — this is correct driver behavior. The MT7996 iftypes_ext_capa array registers .eml_capabilities = IEEE80211_EML_CAP_EMLSR_SUPP only for the AP iftype; the STA iftype has no .eml_capabilities entry. So wpa_supplicant reports 0, and the EML Capabilities Present bit stays clear in all Association Requests. The AP side correctly advertises EMLSR Support (0x0001) in its beacons.

Frequency Separation 31 vs 1 — iPhone advertises a much larger frequency separation (31 × 5 MHz = 155 MHz for STR), which makes sense: it associates 5G + 2.4G, those bands are far apart. Our STA associates 6G + 5G + 2.4G but reports separation = 1 in the Association Request — likely conservative or a driver default.

iPhone 2-link, BPI-R4 STA 3-link — iPhone 16 only associated 5G + 2.4G (no 6G link despite the AP offering one). BPI-R4 STA connected all 3 bands including 6G 320 MHz EHT.

Summary

The MTK SDK hostapd currently adds Link Reconfiguration Support (0x2000) and TID-to-Link ALL_TO_ALL (0x0020) unconditionally — there's even a TODO comment in the source saying TID-to-Link should be advertised based on driver support, not hardcoded. The ext_mld_capa_and_ops field is properly consistent in current code (both the ML Control bit and the subelement are under the same condition), but the feature needs explicit opt-in via emlsr_on_one_link=1. The client-side comparison above confirms EML Capabilities are correctly absent from STA Association Requests on both iPhone 16 and MT7996-based STAs.

cookiemonster · May 13, 2026, 7:47pm

(https://www.rtings.com/router/learn/research/wifi-7-mlo)

However, none of the tested routers advertise support for Aligned Target Wake Time (TWT) or Dynamic Link Reconfiguration (also known as Link Reconfiguration Operation). Without Aligned TWT, multi-link power-saving schedules can't be synchronized across bands, which may reduce power efficiency compared to fully aligned implementations. And without Dynamic Link Reconfiguration, routers can't add or remove links during operation. Though they can still steer traffic between already-established links. In other words, today's Wi-Fi 7 routers largely implement the minimum viable version of MLO, rather than its most advanced form.

TWT isn't anywhere. Just asked if bleeding edge MTK blobs had it.

Note: A lot of clients can't do 320Mhz and you are just supposed to know that.

woziwrt · May 14, 2026, 3:28am

Thanks for the RTINGS reference — aligns with what we're seeing in practice.

On Aligned TWT: got confirmation directly from MTK — the MT7996 (Connac 3 platform) does not support Aligned TWT, so it's intentionally absent from both the mt76 driver and hostapd. Your BT8 flag from post #4 was likely from the HE MAC Capabilities element, which has its own separate Aligned TWT field.

On 320 MHz: clients that don't support it negotiate a lower channel width automatically — standard 802.11 behavior. For users who want to explicitly limit the 6 GHz link to 160 MHz, the MLO wizard has a per-link width selector in its Advanced section.

sppmaster · May 14, 2026, 9:30am

Is this going to work an other targets, like Gemtek W1700k for example.

longnt2007 · May 25, 2026, 11:34am

I think it works with any device that uses the Mediatek mt76 driver and has merged all patches from mtk-openwrt-feeds for the mt76 driver. As you can see, my device with mt7992/mt7988d also works. It fixes the 6 dBm maximum power limit for 2.4 GHz by changing the TX power mode from eFuse max to manual (the default LuCI wireless manager doesn't have an option to change it).

woziwrt · May 28, 2026, 5:09am

v3.0.0 — Link Policy tab: open-source MLO band steering + traffic steering

Following up on the earlier discussions about MLMR-STR capabilities and Neg-TTLM negotiation — we've now put both to practical use. v3.0.0 adds a Link Policy tab with a working MLO link steering daemon and a live control UI.

GitHub: https://github.com/woziwrt/mt7996-wifi7-manager
APK: https://github.com/woziwrt/mt7996-wifi7-manager/releases/tag/v3.0.0

Background

The MTK SDK hostapd already exposes the full API for dynamic link management — SET_ATTLM for AP-side link disable/enable, and negotiated_ttlm for TID-to-link mapping negotiation. We've been discussing these in earlier posts at the protocol level. mlo-steerd is a shell daemon that now sits on top of that API and makes real-time decisions.

The script lives at /root/mlo-steerd.sh on the AP router, autostarted via procd with respawn on crash. Source is in the bpi-r4-deploy repo, my_files/mlo-steerd.sh.

Algorithm 1 — Band steering (SET_ATTLM)

The daemon polls every 10 seconds and computes a weighted score per link:

score = SNR_normalized × 60%  +  (100 − tx_retries%) × 30%  +  (100 − channel_busy%) × 10%

SNR is normalized over a per-link soft zone ([SNR_HARD_LOW .. SNR_HARD_HIGH]), giving a 0–10000 integer. The decision table:

Condition	Action
SNR < hard_low (2 dB for 6G, 0 dB for 5G)	Immediate disable
SNR > hard_high AND retries < 15%	Immediate enable
score < 4000	Disable
score > 6000	Enable
4000 ≤ score ≤ 6000	No change (hysteresis)

Priority order: 6G evaluated first, 5G only if 6G already disabled — client is never left with no link. 30-second cooldown between actions.

For EMLSR clients (iPhone, max_simul_links=1) this is the only mechanism — band steering via SET_ATTLM, no Neg-TTLM.

Algorithm 2 — Traffic steering (Neg-TTLM)

When all links are up and an MLMR client is connected (max_simul_links > 1, in our setup the BPI-R4 running as MLO STA), the daemon sends a negotiated_ttlm request mapping traffic classes to optimal bands:

AC	TIDs	Links	Rationale
Background (BK)	1, 2	2.4G + 5G	Bulk transfers — spare 6G for latency-sensitive
Best Effort (BE)	0, 3	All	General traffic — full capacity
Video (VI)	4, 5	5G + 6G	High throughput, low latency — skip 2.4G
Voice (VO)	6, 7	5G only	Minimum latency — stable mid-band, no 6G range risk

Verified live on MT7996 (2026-05-27). The client accepts and routes accordingly:

hostapd_cli -i ap-mld-1 get_neg_ttlm 3e:35:54:dc:99:02
Link Mapping:   uplink  downlink
TID 0:          0x0007  0x0007   ← BE → all links
TID 1:          0x0003  0x0003   ← BK → 2.4G+5G
TID 2:          0x0003  0x0003
TID 3:          0x0007  0x0007
TID 4:          0x0006  0x0006   ← VI → 5G+6G
TID 5:          0x0006  0x0006
TID 6:          0x0002  0x0002   ← VO → 5G only
TID 7:          0x0002  0x0002

One implementation detail worth noting: SET_ATTLM and Neg-TTLM cannot be active simultaneously — issuing negotiated_ttlm request while A-TTLM is running returns "Busy: A-TTLM is on-going". The daemon handles this correctly: before any SET_ATTLM call it tears down active Neg-TTLM mappings, and re-applies them when all links come back up.

Link Policy tab

The new tab (only shown when an MLO AP is configured):

Live view: MLMR client (BPI-R4 STA, 3/3 links, Neg-TTLM active) + EMLSR client (iPhone, 6G only)

Daemon control — start/stop, status dot + PID
Steering override — three buttons: Auto / All links ON / 5G only, written to UCI mlo-steerd.global.mode, picked up on next poll cycle without restart
Link status — live noise floor per band (iw survey)
MLO clients — EMLSR vs MLMR, per-link signal, active Neg-TTLM mapping per AC for MLMR clients
Daemon log — last 25 lines of /tmp/steerd.log

Install

scp luci-app-wifimgr-3.0.0-r20260528.apk root@192.168.1.1:/tmp/
ssh root@192.168.1.1 'apk add --allow-untrusted --no-network /tmp/luci-app-wifimgr-*.apk'

Requires OpenWrt with MTK SDK (kernel 6.12.x, mt76, MLO-capable hostapd).

The thresholds are currently hardcoded in the daemon script — the next logical step would be UCI-configurable values exposed in the UI. If anyone tests this in different RF environments or with other MLMR clients, would be interested to hear how the algorithm holds up.

longnt2007 · May 28, 2026, 6:01pm

Which device did you use to test MLMR? Does this prove that the current MT76 driver also supports MLMR mode if we merge all patches from the MTK feeds repo? I only have the MT7925, and it shows EMLSR.

EDITED: nvm, I found that MLMR mode only works when the client connects to both 5G and 6G channels, but most WiFi 7 routers sold in China region only have a 5G channel

woziwrt · May 31, 2026, 6:59pm

For testing, I am using two identical BPI-R4 routers, both equipped with a BE14 card - one as an MLD AP and the other as an MLD STA.