MT7996 (BPI-R4) 2.4GHz: silent data-plane failure with IoT clients

MT7996 (BPI-R4) 2.4GHz: silent data-plane failure with IoT clients — full diagnostic case

Platform: Banana Pi BPI-R4, MediaTek MT7996E (0x14c3:0x7990 / 0x14c3:0x6639) OS: OpenWrt 25.12.4 (r32933-4ccb782af7), target mediatek/filogic, aarch64_cortex-a53 Driver/firmware: kmod-mt76 / kmod-mt7996e / mt7996 firmware, build 6.12.87.2026.03.19~39c960c3-r2 Date of investigation: 15 July 2026

Summary

Simple 2.4GHz IoT clients associate and complete WPA2 handshakes cleanly on the MT7996 2.4GHz radio, but data-frame delivery to/from them is unreliable to the point that device provisioning protocols fail. Three independent client types are affected. hostapd and kernel logs show no errors, no deauth reason codes, and no driver warnings — the failure is silent at the management layer and only visible in station tx statistics and packet captures. An exhaustive elimination of configuration-level causes was performed; none resolved it.

A previous device (SwitchBot Hub 2) exhibited the same incompatibility on this radio months earlier and was worked around by enrolling it on a separate dedicated 2.4GHz AP, where it works. The radio serves modern clients (iPhone, iPad, MacBook) without user-visible issues.

Affected clients and their signatures

Midea PortaSplit AC WiFi module (hostname net_ac_1110): associates, authenticates, completes the 4-way handshake, and obtains DHCP within seconds — every time, on every SSID tried. Its cloud-pairing flow then fails 100% of the time. Packet captures show the failure precisely: the app's local discovery query (UDP broadcast to port 6445) was answered by the AC exactly once in 43ms during one attempt, and never again across five-plus subsequent well-timed attempts, including attempts made seconds after the AC confirmed reachability via ARP. The module's firmware then times out waiting, soft-reboots (observed as repeated full DHCP cycles every 3–6 minutes with rotating source ports), and never advances to its cloud-registration phase — zero DNS queries and zero outbound TCP observed from the device across hours of captures. ICMP to the device is meanwhile perfect: 0% loss, 1–4ms RTT, at -43dBm signal.

Roborock vacuum: the "working" IoT device on this radio — but its station dump shows why that's misleading:

tx packets: 99622
tx retries: 82592
tx failed:  82748

An ~83% AP-to-client frame retry/failure ratio at -66dBm. The device survives only because its protocol retries aggressively. For comparison, an iPad on the same router's 5GHz radio shows ~2% retries over 20M packets.

SwitchBot Hub 2: originally presented as high latency and packet loss on this radio (worked fine on the previous router); currently observed in hostapd logs performing a clean self-initiated disconnect/reconnect cycle roughly every 2.5 minutes — the signature of a client-side watchdog repeatedly concluding its connection is dead while the AP logs nothing wrong.

Configuration causes eliminated (in test order)

Test	Setting / action	Result
Encryption mode	psk2 + CCMP confirmed (no WPA3/SAE on 2.4GHz)	not the cause
PMF / 802.11w	unset (default off) confirmed	not the cause
Client isolation	no isolate option set anywhere	not the cause
DNS/firewall	device never reaches DNS phase; AdGuard sees zero queries	not applicable
WMM	was explicitly wmm='0'; re-enabled	partial improvement: AC went from sending zero data frames ever, to broadcasting discovery beacons (UDP 15000, every ~2s) reliably. Pairing still fails
DTIM	radio0 had default DTIM period: 2 (5GHz had explicit dtim_period='1'); set radio0 to 1	no improvement
Multicast handling	multicast_to_unicast='1' enabled on the interface	no improvement
HE/ax on 2.4GHz	radio was running HE20 (interface-level HT20 overridden); forced radio-level htmode='HT20'	no improvement
Legacy rates	legacy_rates='1' enabled	no improvement
U-APSD	was uapsd='1'; disabled	no improvement
Pristine SSID	fresh wifi-iface (iottest), psk2, simple key, no inherited options	AC joined and handshook cleanly; identical pairing failure
Channel environment	ch 6, noise -83dBm; scan shows typical urban congestion, nothing pathological	not decisive
Client-side factors	phone confirmed on the 2.4GHz SSID, iOS Local Network + Bluetooth permissions granted, app reinstall path checked, multiple pairing modes (same-network and SoftAP) tried, AC hard power-cycled	not the cause

Log evidence

During pairing attempts, logread -f filtered on hostapd/mt76/the client MAC shows only clean events: authentication, association (aid assigned), EAPOL-4WAY-HS-COMPLETED, DHCP ACK. No deauthentication reason codes, no disassociated due to inactivity, no low-ack kicks, no mt76 warnings or errors — across the entire session, including the exact windows in which discovery replies failed to be delivered.

Conclusion

Every configuration-level variable on both the AP side and the client side has been eliminated, including a from-scratch SSID. Association and key exchange are flawless; unicast ICMP is flawless; yet UDP application traffic to/from simple IoT radios fails intermittently-to-always, and one healthy-looking client on the same radio quietly runs an 83% tx-failure rate. Management plane clean, data plane broken, no errors logged. This is consistent with a driver/firmware-level frame-delivery defect in the MT7996 2.4GHz path of the installed mt76 build (2026-03-19), affecting low-capability 802.11n-era client silicon disproportionately — and it closely matches a symptom class previously reported against older mt76 chipsets (see below), suggesting a recurring broadcast/power-save delivery weakness resurfacing in the newest chip.

Related prior reports (same symptom class, older mt76 chipsets)

• openwrt/mt76 #598 — "broadcasts delivery problem" (MT7603/MT7621): power-saving clients on 2.4GHz intermittently stop receiving broadcast frames (including ARP) until they transmit something themselves; the AP sees its outgoing broadcasts go unanswered while client-side capture confirms the frames never arrive. This is the same mechanism as the discovery-reply failures documented above.
• openwrt/mt76 #672 — "Some devices lose connectivity but remain connected to the 2.4 GHz WiFi network" (MT7615E/MT7622): specific client devices stay associated with a clean handshake but lose actual data connectivity — the same associated-but-data-plane-dead signature shown by the SwitchBot Hub 2 and Midea module here.

Neither report covers MT7996; this case appears to reproduce the same family of behavior on the current-generation chipset.

Workaround in production

A Raspberry Pi 4 (running MoOde, already on the LAN) acts as a dedicated dumb 2.4GHz AP for IoT devices. The SwitchBot Hub 2 was successfully enrolled through it after failing identically on the MT7996 radio, and works. The same enrollment path is the planned workaround for the Midea AC.

Open questions for maintainers / forum

1. Are there known MT7996 2.4GHz frame-delivery or power-save buffering fixes in mt76 more recent than the 2026-03-19 snapshot that ships in OpenWrt 25.12.4? Is a backport candidate identified?
2. Were the root causes of #598 and #672 ever identified, and could the equivalent code path exist in mt7996e?
3. Is there a recommended debugfs/tracing knob on mt7996e to capture per-station frame-drop causes to make this report more actionable?
4. Others on BPI-R4 + 25.12.x with 802.11n-only IoT clients: do your station dumps show comparable tx failed ratios?

Filing venues

• Driver issue: github.com/openwrt/mt76/issues (reference #598 and #672 as related)
• Community visibility: the BPI-R4 thread on the OpenWrt forum — short summary + link to the GitHub issue

# MT7996 (BPI-R4) 2.4GHz: silent data-plane failure with IoT clients — full diagnostic case

Platform: Banana Pi BPI-R4, MediaTek MT7996E (0x14c3:0x7990 / 0x14c3:0x6639)
OS: OpenWrt 25.12.4 (r32933-4ccb782af7), target mediatek/filogic, aarch64_cortex-a53
Driver/firmware: kmod-mt76 / kmod-mt7996e / mt7996 firmware, build 6.12.87.2026.03.19~39c960c3-r2
Date of investigation: 15 July 2026

Summary

Simple 2.4GHz IoT clients associate and complete WPA2 handshakes cleanly on the MT7996 2.4GHz radio, but data-frame delivery to/from them is unreliable to the point that device provisioning protocols fail. Three independent client types are affected. hostapd and kernel logs show no errors, no deauth reason codes, and no driver warnings — the failure is silent at the management layer and only visible in station tx statistics and packet captures. An exhaustive elimination of configuration-level causes was performed; none resolved it.

A previous device (SwitchBot Hub 2) exhibited the same incompatibility on this radio months earlier and was worked around by enrolling it on a separate dedicated 2.4GHz AP, where it works. The radio serves modern clients (iPhone, iPad, MacBook) without user-visible issues.

Affected clients and their signatures

Midea PortaSplit AC WiFi module (hostname net_ac_1110): associates, authenticates, completes the 4-way handshake, and obtains DHCP within seconds — every time, on every SSID tried. Its cloud-pairing flow then fails 100% of the time. Packet captures show the failure precisely: the app's local discovery query (UDP broadcast to port 6445) was answered by the AC exactly once in 43ms during one attempt, and never again across five-plus subsequent well-timed attempts, including attempts made seconds after the AC confirmed reachability via ARP. The module's firmware then times out waiting, soft-reboots (observed as repeated full DHCP cycles every 3–6 minutes with rotating source ports), and never advances to its cloud-registration phase — zero DNS queries and zero outbound TCP observed from the device across hours of captures. ICMP to the device is meanwhile perfect: 0% loss, 1–4ms RTT, at -43dBm signal.

Roborock vacuum: the "working" IoT device on this radio — but its station dump shows why that's misleading:

tx packets: 99622
tx retries: 82592
tx failed:  82748

An ~83% AP-to-client frame retry/failure ratio at -66dBm. The device survives only because its protocol retries aggressively. For comparison, an iPad on the same router's 5GHz radio shows ~2% retries over 20M packets.

SwitchBot Hub 2: originally presented as high latency and packet loss on this radio (worked fine on the previous router); currently observed in hostapd logs performing a clean self-initiated disconnect/reconnect cycle roughly every 2.5 minutes — the signature of a client-side watchdog repeatedly concluding its connection is dead while the AP logs nothing wrong.

Configuration causes eliminated (in test order)

Test	Setting / action	Result
Encryption mode	psk2 + CCMP confirmed (no WPA3/SAE on 2.4GHz)	not the cause
PMF / 802.11w	unset (default off) confirmed	not the cause
Client isolation	no isolate option set anywhere	not the cause
DNS/firewall	device never reaches DNS phase; AdGuard sees zero queries	not applicable
WMM	was explicitly wmm='0'; re-enabled	partial improvement: AC went from sending zero data frames ever, to broadcasting discovery beacons (UDP 15000, every ~2s) reliably. Pairing still fails
DTIM	radio0 had default DTIM period: 2 (5GHz had explicit dtim_period='1'); set radio0 to 1	no improvement
Multicast handling	multicast_to_unicast='1' enabled on the interface	no improvement
HE/ax on 2.4GHz	radio was running HE20 (interface-level HT20 overridden); forced radio-level htmode='HT20'	no improvement
Legacy rates	legacy_rates='1' enabled	no improvement
U-APSD	was uapsd='1'; disabled	no improvement
Pristine SSID	fresh wifi-iface (iottest), psk2, simple key, no inherited options	AC joined and handshook cleanly; identical pairing failure
Channel environment	ch 6, noise -83dBm; scan shows typical urban congestion, nothing pathological	not decisive
Client-side factors	phone confirmed on the 2.4GHz SSID, iOS Local Network + Bluetooth permissions granted, app reinstall path checked, multiple pairing modes (same-network and SoftAP) tried, AC hard power-cycled	not the cause

Log evidence

During pairing attempts, logread -f filtered on hostapd/mt76/the client MAC shows only clean events: authentication, association (aid assigned), EAPOL-4WAY-HS-COMPLETED, DHCP ACK. No deauthentication reason codes, no disassociated due to inactivity, no low-ack kicks, no mt76 warnings or errors — across the entire session, including the exact windows in which discovery replies failed to be delivered.

Conclusion

Every configuration-level variable on both the AP side and the client side has been eliminated, including a from-scratch SSID. Association and key exchange are flawless; unicast ICMP is flawless; yet UDP application traffic to/from simple IoT radios fails intermittently-to-always, and one healthy-looking client on the same radio quietly runs an 83% tx-failure rate. Management plane clean, data plane broken, no errors logged. This is consistent with a driver/firmware-level frame-delivery defect in the MT7996 2.4GHz path of the installed mt76 build (2026-03-19), affecting low-capability 802.11n-era client silicon disproportionately — and it closely matches a symptom class previously reported against older mt76 chipsets (see below), suggesting a recurring broadcast/power-save delivery weakness resurfacing in the newest chip.

Related prior reports (same symptom class, older mt76 chipsets)

• [openwrt/mt76 #598 — "broadcasts delivery problem"](https://github.com/openwrt/mt76/issues/598) (MT7603/MT7621): power-saving clients on 2.4GHz intermittently stop receiving broadcast frames (including ARP) until they transmit something themselves; the AP sees its outgoing broadcasts go unanswered while client-side capture confirms the frames never arrive. This is the same mechanism as the discovery-reply failures documented above.
• [openwrt/mt76 #672 — "Some devices lose connectivity but remain connected to the 2.4 GHz WiFi network"](https://github.com/openwrt/mt76/issues/672) (MT7615E/MT7622): specific client devices stay associated with a clean handshake but lose actual data connectivity — the same associated-but-data-plane-dead signature shown by the SwitchBot Hub 2 and Midea module here.

Neither report covers MT7996; this case appears to reproduce the same family of behavior on the current-generation chipset.

Open questions

1. Are there known MT7996 2.4GHz frame-delivery or power-save buffering fixes in mt76 more recent than the 2026-03-19 snapshot that ships in OpenWrt 25.12.4? Is a backport candidate identified?
2. Were the root causes of [#598](https://github.com/openwrt/mt76/issues/598) and [#672](https://github.com/openwrt/mt76/issues/672) ever identified, and could the equivalent code path exist in mt7996e?
3. Is there a recommended debugfs/tracing knob on mt7996e to capture per-station frame-drop causes to make this report more actionable?
4. Others on BPI-R4 + 25.12.x with 802.11n-only IoT clients: do your station dumps show comparable tx failed ratios?

Filing venues

• Driver issue: [github.com/openwrt/mt76/issues](https://github.com/openwrt/mt76/issues) (reference #598 and #672 as related)
• Community visibility: the [BPI-R4 thread on the OpenWrt forum](https://forum.openwrt.org/t/a-new-dual-10g-router-based-on-filogic-880-banana-pi-bpi-r4/163861) — short summary + link to the GitHub issue

Start by reproducing the MT7996 2.4GHz behavior with the documented IoT clients, station dumps, packet captures, and filtered hostapd/mt76 logs. Compare the symptoms with mt76 issues #598 and #672, then investigate the mt7996e debugfs or tracing options mentioned in the report. Done means identifying a reproducible driver or firmware cause and a concrete fix or backport candidate.