The Banana Pi BPI-R4 is one of the most interesting networking platforms currently supported by OpenWrt. Powered by the MediaTek MT7988A quad-core Cortex-A73 processor, dual 10GbE SFP+ ports, and optional WiFi 7 expansion modules, it offers impressive hardware specifications at a relatively affordable price.
In this article, I installed the latest official OpenWrt 25 release on the BPI-R4 and evaluated its wired and wireless performance. The goal was to compare the experience with the stock firmware and identify any issues that users may encounter when deploying OpenWrt on this platform.
Test Setup
For this evaluation, I used the following hardware:
Router
- Banana Pi BPI-R4
- BPI-R4-NIC-BE14 WiFi 7 module
Client Device
- Windows 11 PC
- Intel BE200 WiFi 7 adapter
- Mellanox ConnectX-3 10GbE network card
Network Infrastructure
- 10 Gigabit Ethernet Switch
- Linux server running OpenSpeedTest and iperf3
The router was flashed with the latest official OpenWrt 25 image using Rufus and booted directly from a microSD card.
After the initial boot, I configured a root password, disabled automatic firmware checking, and assigned the WAN interface to the SFP-WAN port while keeping the SFP-LAN port connected to the LAN network.
For all routing tests, Packet Steering was enabled with 128 steering flows and Software Offloading remained disabled.
WAN-to-LAN Performance Testing
One of the most important capabilities of the BPI-R4 is its dual 10GbE connectivity. Naturally, this was the first area I wanted to test.
The test setup was straightforward:
Linux Server → 10GbE Switch → SFP-WAN → BPI-R4 → SFP-LAN → PC
CPU utilization was monitored using btop while throughput measurements were performed with iperf3.
First Test: 4 Parallel Streams
Running iperf3 with four parallel streams resulted in approximately 3.48 Gbps throughput.
While this result is not terrible, what immediately caught my attention was CPU utilization. Almost all traffic processing was handled by Core 0, while the remaining three cores remained mostly idle.
Considering Packet Steering was enabled, I expected the workload to be distributed more evenly across all CPU cores.
Second Test: 16 Parallel Streams
Increasing the number of streams to sixteen surprisingly reduced performance.
Throughput dropped to approximately 2.74 Gbps, while Core 0 remained fully loaded.
The remaining CPU cores showed only minimal activity, typically between 10% and 15%.
Alternative LAN Configuration
I also tested a simplified LAN setup by assigning the LAN network directly to the SFP-LAN interface instead of using the default bridge configuration.
Unfortunately, the results remained largely unchanged, fluctuating between 2.5 and 2.75 Gbps.
Comparison with Stock Firmware
These numbers became even more interesting when compared with my previous testing using the factory firmware supplied by Banana Pi.
Using the same hardware setup, the stock firmware achieved approximately 9.16 Gbps WAN-to-LAN throughput.
This suggests that either OpenWrt 25 is currently missing some optimizations, or there may be an issue with packet steering, driver behavior, or hardware acceleration.
At this stage, I do not have a definitive answer, but it is certainly an area worth further investigation.
WiFi 7 Testing
For wireless testing, I installed the BPI-R4-NIC-BE14 module and connected using an Intel BE200 WiFi 7 adapter running the latest available driver.
The client PC was positioned approximately one meter away from the access point with direct line of sight.
Initial Problem: WiFi Not Working
After installing OpenWrt 25, the MT7966E chipset was detected correctly and all three radios appeared in LuCI.
However, I quickly discovered that none of the configured SSIDs would start.
I tested multiple configurations:
- WiFi 7 (BE)
- WiFi 6 (AX)
- WiFi 5 (AC)
- WPA2 and WPA3 security
- Different channels and bandwidth settings
Nothing worked.
The maximum transmit power was limited to only 7 dBm, which immediately suggested something was wrong.
Fortunately, this issue is already known within the OpenWrt community.
After applying the recommended Device Tree Overlay workaround and rebooting the router, transmit power returned to normal levels and wireless functionality was restored.
WiFi 7 Performance on 6 GHz
160 MHz Channel Width
The first test used:
- 6 GHz band
- Channel 37
- 160 MHz bandwidth
- WPA3-SAE security
Windows reported a link speed of approximately 2882 Mbps.
Running OpenSpeedTest produced excellent results:
- Download: approximately 1782 Mbps
- Upload: approximately 1849 Mbps
Multiple test runs produced very similar results.
Interestingly, iperf3 throughput was slightly lower, reaching around 1.6 Gbps with eight parallel streams.
320 MHz Channel Width
Next, I increased the bandwidth to 320 MHz.
Windows immediately reported much higher link rates, reaching 5.1 Gbps receive and 3.6 Gbps transmit.
Unfortunately, real-world performance told a different story.
OpenSpeedTest results dropped dramatically:
- Download: approximately 774 Mbps
- Upload: approximately 897 Mbps
iperf3 results were similarly disappointing.
At least in my test environment, 320 MHz operation performed significantly worse than 160 MHz.
WiFi 7 Performance on 5 GHz
Moving to the 5 GHz band, I configured:
- Channel 60
- 160 MHz bandwidth
- WiFi 7 mode
The results were very impressive.
OpenSpeedTest consistently delivered:
- Download: approximately 1.6 Gbps
- Upload: approximately 1.7 Gbps
Compared to the 6 GHz results, the difference was only around 100 to 150 Mbps.
I also attempted to use 320 MHz bandwidth on 5 GHz, but the SSID completely disappeared from client devices. This may be related to regulatory limitations or DFS restrictions.
WiFi 7 Performance on 2.4 GHz
Testing the 2.4 GHz radio in WiFi 7 mode produced more modest but still respectable results.
Using a 40 MHz channel width, OpenSpeedTest achieved:
- Download: approximately 205 Mbps
- Upload: approximately 125 Mbps
Considering how crowded the 2.4 GHz spectrum typically is, these results are perfectly acceptable.
Testing Multi-Link Operation (MLO)
One of the headline features of WiFi 7 is Multi-Link Operation (MLO), which allows multiple radios to work together under a single connection.
OpenWrt 25 includes early support for this feature, so naturally I wanted to test it.
First Attempt
My initial configuration combined:
- 5 GHz @ 160 MHz
- 6 GHz @ 320 MHz
The MLO SSID was visible and clients could connect.
However, diagnostic information showed that only the 5 GHz radio was actually participating in the MLO group.
Second Attempt
After reducing the 6 GHz radio to 160 MHz, MLO started working correctly.
Both radios appeared active and Windows reported simultaneous connectivity on both frequency bands.
The reported link speed was approximately 2882 Mbps / 2882 Mbps.
MLO Performance Results
OpenSpeedTest produced:
- Download: approximately 1.8 Gbps
- Upload: approximately 2.0 Gbps
iperf3 achieved:
- Up to 1.87 Gbps in the forward direction
- Around 1.5 Gbps in reverse mode
These were the best wireless results recorded during all testing.
MLO Stability Issues
Although MLO was functional, I did encounter stability problems.
After approximately 10 to 15 minutes of operation, the client would lose connectivity to the router.
The WiFi connection remained associated, but traffic stopped flowing and the gateway could no longer be reached.
The only reliable solution was disabling and re-enabling WiFi on the client device.
Whether this issue originates from OpenWrt, the MediaTek driver, Intel’s BE200 driver, or my own configuration remains unclear.
Further testing will be required.
Final Thoughts
Based on my initial testing, OpenWrt 25 on the Banana Pi BPI-R4 is already very usable, but there are still several rough edges.
The WiFi 7 implementation is surprisingly capable, especially when operating at 160 MHz on both 5 GHz and 6 GHz bands. MLO support is also promising, although stability improvements are clearly needed.
The biggest concern at the moment is wired routing performance. Achieving only around 2.5–3.5 Gbps when the stock firmware can exceed 9 Gbps suggests there is still work to be done somewhere in the software stack.
Nevertheless, the BPI-R4 remains one of the most exciting OpenWrt platforms currently available, and I expect performance and stability to improve significantly as OpenWrt development continues.
If you are running OpenWrt 25 on a BPI-R4 and have achieved better results, feel free to share your configuration and findings. I would be very interested to compare notes and continue investigating these issues.
