A new dual 10G router based on Filogic 880 (Banana Pi BPi-R4)

ssdnvv · May 16, 2026, 6:54am

But this one should be pretty easy, right (haven't done it yet, wanted to upgrade 24.10.6 to 25.12.4 yesterday but there was some glitch in ASU so I need to wait till today)? Just ssh to your /etc/config/network and rename eth1 to sfp-lan and eth2 to sfp-wan accordingly before updating, save it without restarting network or rebooting, do the upgrade and everything should be fine?

titoum · May 16, 2026, 7:35am

i though would be easy as well

i did that but i had to slightly modify the br-lan as well to include sfp Lan

buz · May 16, 2026, 3:00pm

FWIW, mine fell over because somehow I screwed up vlans in the process, in the end rebuilding was easier. I do believe it's doable in simple configs.

titoum · May 16, 2026, 3:11pm

that is still need to do vlan....but it seems so painful to do.

ssdnvv · May 16, 2026, 5:13pm

Hm...

But if you do a "replace all" (so for VLANs e.g. sfp-lan.1) it would work? I mean there is nothing else that does the magic, right?

edit: I failed as well, but cannot really tell what is the difference

titoum · June 8, 2026, 9:07am

nha i mean configure them

i dont have any atm...a bit lazy

blunden · June 25, 2026, 9:49pm

Both OpenWrt and VyOS minimize writes to the storage so no, it shouldn't be a problem unless you do excessive logging or something like that.

longnt2007 · July 2, 2026, 10:49am

They released new source code for TOPS (NPU) today.

BPI-SINOVOIP · July 7, 2026, 11:32am

BPI-R4-NIC-BE14 is a 51x82mm WiFi7 module with MediaTek MT7995AV supports Wi-Fi7 technology and feature IEEE802.11a/b/g/n/ac/ax/be compliant,2.4GHz 2x2, 5GHz 3x3 3ss, and 6GHz 3x3 3ss BE13500 Wi-Fi subsystem. The MT7995AV offers feature-rich wireless connectivity at high standards and delivers reliable, cost-effective throughput from an extended distance.

doiser4 · July 10, 2026, 10:07am

Do you know if these changes are already included in the latest OpenWRT snapshot?

longnt2007 · July 10, 2026, 10:33am

Hi, here's a quick summary based on what I've looked into:

The good news first: the underlying NPU hardware is genuinely capable — it's a 5-core design (1 mailbox/management core + 4 independent execution cores) that offloads tunnel encap/decap off the CPU entirely, and it also has some secondary features like Adapter Forward, L4S, and rate-limit support built in.

That said, a few things to keep in mind:

Source is only in mtk-openwrt-feeds, MediaTek's own feed repo — it's not in mainline OpenWrt or the official snapshot, so you won't get it unless you pull that feed in explicitly.
Scope is narrow — it only covers a handful of tunnel protocols (GRE/GRETAP, L2TP, PPTP, VXLAN) plus multicast. It's not a general-purpose NPU like Airoha's (which can also do WiFi offload), and crypto/encrypted-tunnel support isn't included — you'd need to merge MediaTek's separate crypto driver on top for that.
It's built around MediaTek's vendor HNAT driver rather than the upstream NFT flow offload path — so if your setup runs on upstream NFT offload instead of HNAT, expect some rough edges.

robertdirosa · July 15, 2026, 8:24pm

2.4GHz data-plane failures with IoT clients on 25.12.4 — filed as mt76 issue #1101

I've spent a day diagnosing why simple 2.4GHz IoT devices (Midea AC WiFi module, SwitchBot Hub 2) can't complete provisioning on the BPI-R4, and I think it's worth flagging here: association, WPA2 handshake, and DHCP are flawless every time, unicast ICMP is perfect (0% loss, -43dBm), but UDP application traffic silently fails — the AC answered a local discovery broadcast exactly once, then never again across many well-timed attempts. Nothing appears in hostapd or kernel logs. No errors, no deauth reasons, no mt76 warnings.

The telling stat: a Roborock vacuum on the same radio, which nominally "works," shows tx retries 82592 / tx failed 82748 on 99622 tx packets (~83%) in its station dump. An iPad on the 5GHz radio: ~2%. Modern clients are fine; 802.11n-era IoT silicon is not.

I eliminated the full config space before concluding driver: WMM, DTIM 1, multicast_to_unicast, HE20→HT20, legacy_rates, U-APSD off, PMF off, no isolation, plus a from-scratch test SSID — identical failure everywhere. Full writeup, captures, and station dumps here:

github.com/openwrt/mt76

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

opened 07:25PM - 15 Jul 26 UTC

robertdirosa

<html> <body> <html><head></head><body><h1>MT7996 (BPI-R4) 2.4GHz: silent data-p…lane failure with IoT clients — full diagnostic case</h1> <p><strong>Platform:</strong> Banana Pi BPI-R4, MediaTek MT7996E (0x14c3:0x7990 / 0x14c3:0x6639) <strong>OS:</strong> OpenWrt 25.12.4 (r32933-4ccb782af7), target mediatek/filogic, aarch64_cortex-a53 <strong>Driver/firmware:</strong> kmod-mt76 / kmod-mt7996e / mt7996 firmware, build <code>6.12.87.2026.03.19~39c960c3-r2</code> <strong>Date of investigation:</strong> 15 July 2026</p> <h2>Summary</h2> <p>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.</p> <p>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.</p> <h2>Affected clients and their signatures</h2> <p><strong>Midea PortaSplit AC WiFi module</strong> (hostname <code>net_ac_1110</code>): 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.</p> <p><strong>Roborock vacuum</strong>: the "working" IoT device on this radio — but its station dump shows why that's misleading:</p> <pre><code>tx packets: 99622 tx retries: 82592 tx failed: 82748 </code></pre> <p>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.</p> <p><strong>SwitchBot Hub 2</strong>: 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.</p> <h2>Configuration causes eliminated (in test order)</h2> 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 <h2>Log evidence</h2> <p>During pairing attempts, <code>logread -f</code> filtered on hostapd/mt76/the client MAC shows only clean events: authentication, association (aid assigned), <code>EAPOL-4WAY-HS-COMPLETED</code>, DHCP ACK. No deauthentication reason codes, no <code>disassociated due to inactivity</code>, 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.</p> <h2>Conclusion</h2> <p>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.</p> <h2>Related prior reports (same symptom class, older mt76 chipsets)</h2> <ul> <li><a href="https://github.com/openwrt/mt76/issues/598">openwrt/mt76 #598 — "broadcasts delivery problem"</a> (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.</li> <li><a href="https://github.com/openwrt/mt76/issues/672">openwrt/mt76 #672 — "Some devices lose connectivity but remain connected to the 2.4 GHz WiFi network"</a> (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.</li> </ul> <p>Neither report covers MT7996; this case appears to reproduce the same family of behavior on the current-generation chipset.</p> <h2>Workaround in production</h2> <p>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.</p> <h2>Open questions for maintainers / forum</h2> <ol> <li>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?</li> <li>Were the root causes of <a href="https://github.com/openwrt/mt76/issues/598">#598</a> and <a href="https://github.com/openwrt/mt76/issues/672">#672</a> ever identified, and could the equivalent code path exist in mt7996e?</li> <li>Is there a recommended debugfs/tracing knob on mt7996e to capture per-station frame-drop causes to make this report more actionable?</li> <li>Others on BPI-R4 + 25.12.x with 802.11n-only IoT clients: do your station dumps show comparable <code>tx failed</code> ratios?</li> </ol> <h2>Filing venues</h2> <ul> <li>Driver issue: <a href="https://github.com/openwrt/mt76/issues">github.com/openwrt/mt76/issues</a> (reference #598 and #672 as related)</li> <li>Community visibility: the <a href="https://forum.openwrt.org/t/a-new-dual-10g-router-based-on-filogic-880-banana-pi-bpi-r4/163861">BPI-R4 thread on the OpenWrt forum</a> — short summary + link to the GitHub issue</li> </ul></body></html> </body> </html># 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)](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)](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)](https://github.com/openwrt/mt76/issues/598) and [[#672](https://github.com/openwrt/mt76/issues/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)](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)](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

It looks like the same symptom family as mt76 #598 (power-save clients missing broadcast frames) and #672 (associated but data-dead), now on MT7996.

Setup: BPI-R4, OpenWrt 25.12.4 (r32933), mt76 build 2026-03-19.

If you're on 25.12.x with 802.11n-only IoT clients, I'd be grateful if you could check iw dev <2.4ghz-ap> station dump and post your tx retries / tx failed ratios — more reproductions would help narrow this down.