You’re right. I like to try the latest and I am not disappointed, usually, but if I had to vouch for a specific version than 6.12-main works great!
Same here. The BPI-R4 has been out for quite a while now—according to Banana Pi’s own wiki, since 2023—so we’re already approaching the two-year mark. It also appears to be in mass production, at least based on what Sinovoip has shared, possibly even with a higher production volume than GL.iNet’s current WiFi 7 lineup. But despite all this, there’s still no reliable or fast firmware available. Ironically, even the much cheaper MT7981-based AX3000 routers outperform the R4 in both speed and stability.
In virtually every discussion I’ve seen—whether on the official forum or other community platforms—the most common feedback about the BPI-R4 is consistent: “unstable,” “BE doesn’t work, use AX instead” (yes, even the OpenWRT wiki recommends this), “treat it like a wired router and disable WiFi,” or simply “it just crashes randomly.” As some users half-jokingly put it, we developers are essentially paying to be beta testers, guinea pigs helping BPI debug their platform. And this isn’t cheap hardware—we’re buying these boards, encountering random hardware and software issues, reporting bugs, testing fixes, and ultimately contributing to the improvement of Sinovoip’s or MediaTek’s commercial platform, often without acknowledgement or proper support.
Many in the community defend the R4 by saying it’s a development board aimed at developers, not end users, and that it’s unfair to expect it to behave like a consumer-grade router. That’s a valid point—if Sinovoip were strictly marketing it as a dev board. However, what’s confusing is their mixed messaging. In this forum post, they showcase what looks like the same unmodified R4 board placed inside a larger enterprise-style metal case, labeling it as a “router product design” and announcing plans to “mass produce it.” . A router is defined as enterprise-grade not because it has a metal case, but because it runs highly stable firmware, has been thoroughly tested and certified for compliance, and can operate reliably under a wide range of conditions.
This raises serious concerns. Is this board truly production-ready? Have issues like random disconnects, unstable drivers, poor signal quality, and system-level unresponsiveness actually been addressed? If not, how can it possibly be trusted in a commercial or mission-critical environment? Maybe Sinovoip has access to a proprietary MediaTek firmware that performs better, but if so, that just highlights the frustrating gap between their internal development and what’s publicly available.
It’s hard to imagine anyone confidently deploying this router for livestreaming, enterprise applications, or any scenario requiring stable connectivity, knowing it might drop connections mid-session, randomly lose WiFi, or become completely unresponsive. Without a stable, open-source or well-supported firmware ecosystem, the R4 remains in limbo—neither a dependable dev board nor a viable consumer or enterprise product.
To be fair, I originally bought the R4 for its advertised expandability—things like BE19000 support (which only turned into BE14000 a year later, with very poor real-world performance), MediaTek’s hardware offload and crypto acceleration, and the fact that it was one of the few WiFi 7-capable devices available at the time. It looked promising for experimentation.
But in 2025, we’re seeing WiFi 7 routers from other vendors hitting the market for 100–200 CNY with significantly better speed, signal strength, and firmware support. Some of these have active OpenWRT community support, while brands like GL.iNet offer refined, stable official firmware. Meanwhile, BPI’s firmware—whether open or closed—remains largely unusable: WED (WiFi Ethernet Dispatch) is unstable, and MLO (Multi-Link Operation) still isn’t implemented or even exposed in the UI (e.g., LuCI).
Of course, Sinovoip isn’t the only one that’s fallen behind in the WiFi race—Mikrotik’s WiFi product line is also significantly lagging. But the difference is in the effort. Mikrotik, at least, is transparent about their development direction, and they have decades of track record in both hardware and software. With Sinovoip, I don’t see the same level of effort or accountability. From what’s publicly visible, it feels like they designed the hardware, shipped it, and then largely left the rest to the community to figure out.
Even hardware-level issues—like WiFi module noise (yes, no shielding), poor wall penetration, or severe signal drop-off at medium distances—have been reported in the forums without any clear response or solution from Sinovoip. On the software side, even if Sinovoip had done nothing for a year, you’d expect MediaTek’s SDKs, drivers, or system code to evolve. But according to the Banana Pi wiki, there’s barely anything that shows activity into 2025. The latest firmware builds are already over a year old (e.g., 20240202 and 20240620), and even those builds are broken: with dirty system components, error-ridden LuCI pages, and critical features missing or unstable.
Even if this were “just” a dev board, look at what Raspberry Pi has done—they push out regular firmware updates, maintain a clean software stack, and have a functioning CI pipeline. That’s the kind of standard developers should be able to expect. Unfortunately, the R4 falls short on all of these fronts.
And when we talk about “development,” it’s important to clarify what that typically means. Most developers aren’t working on kernel-level drivers or tuning low-level firmware. Development usually happens in user space—building networking tools, deploying application services, or integrating the system into broader solutions. Think of how AI developers use NVIDIA Jetson boards: they focus on optimizing deep learning models, connecting external peripherals like motors or cameras, and testing in different environments—not writing GPU drivers from scratch.
If the R4 is truly intended only for ultra-low-level, expert firmware and driver developers, then its target audience is extremely narrow. And without solid baseline support—meaning a stable system, working drivers, and usable firmware—it’s unrealistic to expect broader developer adoption. Right now, the R4 seems to demand that you fix the platform before you can actually develop on the platform, which defeats the purpose for most potential users.
4 Likes
That sounds awesome, thats realistically the type of setup Im hoping to achieve. I don’t actually want to run OpenWRT, not that there’s anything wrong with it. But I’m wanting to run SPR which is deployed 99% in docker.
I have no idea if this is a big ask or not, probably is. But would anyone be willing to guide me on the steps I would need to take to compile my own image? Im really wanting to run Alpine Linux. I tried the Alpine U-Boot download and I don’t even know what I’m supposed to do with the directories after opening the archive.
I have no idea what I’m doing when it comes to actually compiling something like that. Especially when I need to add the tx power patch, and possibly other things. Don’t get me wrong, I’m not a complete noob…just when it comes to this lol. I don’t understand a bulk of the terminology used, plus I never even heard of U-Boot until I got the R4.
I do have two AW7916-NPD and one AW7915-BMD on the way from AsiaRF. Hopefully the new WiFi cards alleviate some of the issues for me, but Im only intending it to be temporary, and I have no idea how long they will take to get here anyway. So I still intend to use the BE1400 as soon as I can get it working, and then the other cards will become Mesh nodes using a few Pi’s.
Awesome, bookmarked and will definitely check it out.
I have no idea how to compile software like this, but I have seen Gitea a million times in the Unraid CA on my server. So once I figure out how to even compile the OS to begin with Im definitely going to look into setting up something like that. Only difference is I’d prefer using Alpine Linux because of how light weight it is. So unless someone drops a major update soon, I’m going to have to figure out how to apply the patches I need for my unit and compile my own image. Im going to give yours a shot, but so far not a single image I have tried will let me leave the room and still have usable WiFi.
I didn’t realize it had actually been available for that long already. I thought it was available for purchase more recently. That does kind of make me wonder why even the official drivers don’t work properly.
I mean, you’re not wrong. This is one of the top listings on Amazon and there’s no mention of “development”:
@tutugreen I have noticed pretty much everything you’ve mentioned. My first “hey…wait a minute” moment was when I couldn’t get the mt76 driver working well on my unit. So I figured Id try the official MTK image just to make sure everything was working there…but it wasn’t. The numbers looked better, but the actual performance was just as bad, and it would randomly reboot. At that point I got really concerned that no future support was coming from Mediatek, especially considering that the last version was December of 2024, and not a single “Auto Build” link works on the MTK Feed.
ooooh, but the Blinky lights work on the MTK images, so thats a nice touch 
@ericwoud has a repo with scripts to build arch if you want the easy version.
What I did, and what I would recomment is that you follow the install process of your favourite linux distro onto an empty ssd (which you’ll use with the R4, an sd also works but you’ll need to make sure you have the correct partition layout, there should be some guidance around for that). Make sure you install for ARM64. Following that, make sure you remove the linux-xxx package that comes with your distro and place Frank’s prebuilt bpi-r4.itb kernel in your /boot on the ssd. If you use @frank-s uboot then you’re basically done at this point. Place the ssd on the R4 and enjoy.
For the R4, I only have the main board so wifi untested. The kernel is the one from dangowrt’s branch mt7988-for-next, as he keeps the latest for R4 on this branch name, so it is easy to follow.
However, for the R4 my script is still in experimental phase.
Anyway, this is getting off topic, so I will refer to:
@meehien Honestly that sounds incredibly easy, and I know Apline should have support for the R4.
On a side note, does the AUR possibly have anything of use for the R4 or BE14? If so I might try Arch if Alpine doesn’t work out.
That actually sounds incredibly easy. But in this specific case, I’m lost at step one lol.
How do I do that on the R4? I have no other ARM based systems I could run an installer on.
I do have a small NVME drive in the R4 that I intend to run the OS from, so that part is covered.
Then I need to install U-Boot from @Frank-W onto the eMMC to enable booting the OS from the NVMe drive, which I was never able to figure out how to do correctly. That was actually my first post here on the forums lol. That thread got put on the back burner when I started noticing all the other issues.
I know the main issue is simply the fact that I have never done this type of setup before. So I have no understanding of what files go where and why or what they do. Plus im probably way over complicating things. I know the moment it finally clicks im probably going to feel really stupid lol. 
Amen, you said it all properly.
i should have dig a bit more about this product before buying it (i was misled by my previous raspberry experience). Fortunately, i don’t plan to use it for wifi but i found it a bit triggering to see variant release of the R4 when the original product is not even fully working as expected and properly supported by the vendor.
I have the very same setup - the two NPDs + a custom aluminium case are getting actively cooled by an 120mm fan. That way I have 2x2 6GHz WIFI in two rooms (the 2,4GHz disabled) + a central 4x4 2,4GHz (all serving one floor). The setup is completely stable that far.
Good to hear that!
How are the TX and RX values of AW7916-NPD ?
I can reach 1,2Gbit with iperf2 on a laptop with intel be-card (antennas installed in the ceiling, so from a distance of roughly 3 - 4 meters) on 5 GHz AX, didn’t test it on 6 GHz so far. I had a very similar setup with 2×7916-NPD + 1×7915-NP1 installed on Turris Omnias with similar speeds. I am currently changing the antennas (before: 2,4/5GHz only with low antenna gains that don’t outperform the attenuation losses because of long cabling, after: omniband antennas with higher gain) so I’ll need some days to post the evidence.
I’m running a BPi-R4 (BE1400 Wi-Fi) as my primary home router on OpenWrt 24.10.0-rc5 (r28304-6dacba30a7). Haven’t upgraded to the stable 24.10.1 release yet, but plan to soon.
Uptime & stability:
- 65 days uptime (aside from a power outage two months ago):
16:39:34 up 65 days, 5:08, load average: 0.07, 0.11, 0.04 - No unexpected reboots—system’s been fairly stable overall.
Wi-Fi:
- Wi-Fi 7: doesn’t work at all.
- Wi-Fi 6: works, but several devices won’t connect—my Blink cameras, an iPad (3rd gen), and my TCL TV (though it’s usually on Ethernet).
- WED (Wireless Ethernet Dispatch) is not enabled.
- Speed: close to the router I see 700+ Mbps; about 10–15 m away it can drop to ~20 Mbps.
- Even after moving the network printer within ~5 m, it still hiccups occasionally.
Wired & services
- NVMe SSD installed; running four Podman containers with MacVLAN networking—zero issues.
- Wired gigabit routing and throughput are solid.
- Gaming: I stream PC games to my tv over LAN using Moonlight + Sunshine for family game nights - no latency issues at all.
- DNS & PXE: running BIND9 as my main home DNS server (for external-dns) and using it to network-boot my k8s cluster—works flawlessly.
Disk & memory snapshot
# free (memory)
total used free shared buff/cache available
Mem: 4025012 565096 199680 2924 3260236 3369740
Swap: 0 0 0
# lsblk (block devices)
NAME MODEL SIZE
mmcblk0 29.8G
└─…
nvme0n1 Samsung SSD 990 EVO 1TB 931.5G
└─nvme0n1p3 915.5G
Overall: fine as a wired router, but Wi-Fi coverage and stability remain the weak link.
Looking ahead I’m on the hunt for hardware with proper Wi-Fi 7 and OpenWrt support—and at least 2 GB of RAM (harder to find than it sounds). The Banana Pi seemed the best option, but its Wi-Fi performance was a letdown.
What Wifi 6 card do you use?
I don’t know. Comes in bundle on Nov 2024. Anyhow I can find this out without disassembly the whole device?
This is what lspci shows besides SSD:
0000:00:00.0 PCI bridge [0604]: MEDIATEK Corp. Device [14c3:7988] (rev 01)
0000:01:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7990]
0001:00:00.0 PCI bridge [0604]: MEDIATEK Corp. Device [14c3:7988] (rev 01)
0001:01:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7991]
0002:00:00.0 PCI bridge [0604]: MEDIATEK Corp. Device [14c3:7988] (rev 01)
And just did an iperf3:
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 0 4.12 MBytes
[ 5] 1.00-2.00 sec 122 MBytes 1.03 Gbits/sec 0 4.12 MBytes
[ 5] 2.00-3.00 sec 117 MBytes 985 Mbits/sec 0 4.12 MBytes
[ 5] 3.00-4.01 sec 116 MBytes 965 Mbits/sec 0 4.12 MBytes
[ 5] 4.01-5.00 sec 111 MBytes 941 Mbits/sec 0 4.12 MBytes
[ 5] 5.00-6.00 sec 118 MBytes 987 Mbits/sec 60 4.12 MBytes
[ 5] 6.00-7.00 sec 98.9 MBytes 829 Mbits/sec 0 4.12 MBytes
[ 5] 7.00-8.00 sec 107 MBytes 900 Mbits/sec 0 4.12 MBytes
[ 5] 8.00-9.00 sec 114 MBytes 961 Mbits/sec 0 4.12 MBytes
[ 5] 9.00-10.01 sec 111 MBytes 922 Mbits/sec 0 4.12 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 1.10 GBytes 947 Mbits/sec 60 sender
[ 5] 0.00-10.06 sec 1.10 GBytes 942 Mbits/sec receiver
Have never seen this big numbers before, but I’m 5m away right now, and in direct sight.
- Tried a few things I found here and other places. Nothing works. Two of the three radios only put out 6 and 7 dbm.
- Still waiting on a new OpenWRT 24.10.x version to fix it properly.
- Besides the radio troubles it’s crazy unstable and hot. By far the biggest waste of a good chunk of money in a long time. So still laying on my desk instead of running as main router. Would have been far better off putting the money in a proper wifi7 accesspoint and keeping my current router.
Thats awesome to hear. Hopefully I’ll have mine soon, they were apparently out of stock so it was a two week delay.
I hear that a-lot, that this thing runs hot. I either haven’t stressed it enough, which is very likely right now, or I did a decent job prepping. I swapped out all the thermal pads with higher quality ones and figured I’d spend the time waiting on my new WiFi cards working on the cooling. Had a little too much fun with it.
-
Added NVMe heatsinks directly below the WiFi card day one.
-
Heat sink from an old motherboards north bridge for the SFP cage. Oddly satisfying fit.
-
Then came the 3D printing. Custom designed top cover with three 40mm fans. The 12v Winsinn fans from Amazon actually move a decent amount of air, used a small buck converter to keep the fan noise down. Intentionally choked a majority of the airflow on the top, to force air to come in the side vents by the WiFi card.
-
For good measure I added some steel mesh to the bottom of the cover and ensured it comes in contact with the sides of the aluminum casing.
1 Like
Your top cover looks great - any chance to have it published for download anywhere?
Already replaced thermal pads immediately and added a heatsink on top of the sfp ports.
In the process of adding 2 fans in the cover and will power those from gpio.
Those nvme heatsinks are a great idea!