Good question. Im also not mad but have almost the same exact story as you. bought the 8gb ram version and I’ve been tinkering with it about a month. Then my wrt3200acm died so the r4 had to step it up.
I am using bpi-r4 as my main router I just have the be14000 turned off because I have a few access points around my house that work fine because the wrt3200acm never had the strongest wifi anyway.
I’ve started building openwrt with the stuff I like and the r4 works great as my main router.
The OpenSource OpenWRT office have already support BPI-R4 + BE14.
https://firmware-selector.openwrt.org/?version=24.10.1&target=mediatek%2Ffilogic&id=bananapi_bpi-r4
you can download the latest images , then upgrade the BPI-R4.
Finally you only configrate these interface on 192.168.1.1 web UI.
Just tested my wifi and when I am in the same room (10 feet from router) as the 24.10.1 build. I get 710Mbps down / 31Mbps up.
I have 1Gbps /35Mbps internet. So that works great.
If I put one wall between me and the router (20ft) it drops to 120Mbps down/ 31Mbps up…2 walls (about 40ft) 0 down / 0 up.
wifi7 settings BE/6GHz/auto/80MHz/ transmit power (driver default) 7 dBm.
I also like OP can’t find out the answers to his 3 questions. will BE19000 fix issues and/or is BE14000 a lost cause?
Again not making a complaint I am having fun with the system. I just have a hard time putting together all the different information that is all spread out.
And it really doesn’t help that mediatek firmware is also called openwrt-mtk. (in my opinion)
Very, short answer:
→ Yes, you are to early 
In my view, this board is a development board for software developer:
→ It do not mean that is will not work. But …
You may have the wrong board and or wifi NIC:
“will BE19000 fix issues” → not sure there is an issue (issue is the thinking that this a working router board) Did you see the heatsink of BE14? You can look very easy on your money:
There are use cases for BE19 but look at the amount of antenna:
So what are your needs?
If you suffer from 7dBm issue (max transmit power) then might be affected by a bug of the WiFi card - it seems some cards are left in “testing” mode from the factory and their eeprom limits the transmit power to 7dBm.
But there are some firmware alternative which included a fix (basically if the transmit limit is 7dBm or less they are overriding that value with proper setting) - but this fix is not (yet) included in official OpenWrt. Also the original OpenWrt version of the manufacturer (but this is a very very old version of OpenWrt) does not suffer from that problem - perhaps they included a similar feature…
The Official Images for the R4 with the BE1400 do work-ish. Numerous people, myself included, are limited to a tx_power of 6 dBm on all radios. There’s a workaround but even it doesn’t work for everyone, myself included again.
So sadly, as of right now, the official OpenWRT is essentially useless if you want to use the WiFi.
Well thats actually a little relieving. Im Enjoying messing around with it, I’ve even designed my own top plate for the stock metal case to add fans. And I’ll likely design my own a full enclosure soon so I can fit larger heatsinks.
I more or less was getting worried that this thing was just going to end up dying out due to hardware issues or lack of support from the manufacturer.
I definitely have a WiFi module with the bad EEPROM issue, which only adds to the difficulty of troubleshooting and trying different images.
I currently have functioning AP, crappy but functional, and using SophosXG as my firewall which is fine. So I wouldn’t say I have an immediate “need”. But I definitely want to eventually have a fully functional router that I can run SPR on to replace both.
I have been doing my best to follow this issue, there seems to have been at-least two “fixes” for it but the first didn’t work for me. And the other im not 100% sure on, it hasn’t been picked up by the official OpenWRT image, not even the snapshot builds yet. I have tried a few images that say it’s included, but it shows a dBm value of 255, but the actual range is still completely crippled.
Would you happen to know of any I should try and check out? I’ve tried a few I have found on here but none of them seemed to fix the issue. Even the latest MTK image performs terribly.
That and Im fine running OpenWRT for now, but ultimately my goal is a typical Linux Distro that I can run SPR on top of.
I have three in my home I use as part of my primary infrastructure. Weeks of finding the right combination resulted in having stable uptime on access points and the main router. I do my own builds and apply some community patches as well as browse the mtk-openwrt-feeds for critical items. Two are POE powered.
I’m able to achieve at least a month long uptime so far. Speeds on my devices peek at about 1500mbs both up and down. I can consistently achieve these high speeds. I can use my Meta Quest 3 and stream without lag with multiple other devices doing their own thing.
Big caveat, only 802.11ax(e) really works. 802.11BE mode absolutely horrible in its current iteration.
Basically, I’m using openwrt 24.10.1 with a few patches. Most notably, the “use_defaults=true” patch, along with wireless reg-db patches. Works great. A few other ‘fix memory leak’ and ‘filter’ patches.
That being said, I’m exploring changing from openwrt to Fedora CoreOS. I think its possible if I provide the uboot overlays right. Haven’t had a chance to actually do this.
Honestly, I’d be fine with that. The only WiFi7 device in my entire house is my nieces iPhone 16. So If I had stable 6e I’d be thrilled. How is your range though? Mine becomes completely unusable at around 10ft
Would you be willing to share your image? Or the process you used to create it? I haven’t heard of a single one of the patches you just mentioned.
Compiling an entire OS is completely new to me, and then needing to add patches, knowing which patches I need, etc, it gets overwhelming pretty quick. It’s probably not that difficult once you know what you’re doing, but thats completely uncharted territory for me.
I am using two R4 with the BE1400 as: my main router (8GB ver) and an AP extender (4GB). They replaced the two R3s I was using previously and the WiFi signal is comparable. I’m also using the standard case and assembled the router with the original video instructions, i.e. no fancy mods.
The software I use is: @frank-w kernel and a self build version on a ArchLinuxArm. For the BE1400 I use the firmware from the main kernel repo (or linux-firmware package on arch).
So far I have no complaints, all 3 bands are working. The 6GHz is 160MHZ only and a bit slower than the 5GHz but that is about the only limitation I noticed (and hoping it will get fixed eventually).
Temps are: CPU:66.5, NVME: 54.8, SFP: 68.8, WIFi: 58.0 (all *C) with the standard fan cooler and the case closed. Room temp is 20*C.
I’ve been on these forum for quite some time now, but apart from some idealistic optimisations that people would like to have, I’m not really sure what the complaints are about. Maybe I’ve just been lucky with the hardware I got.
You should mention kernel version / branch 
I put a copy of my latest image on github.
Release Built 8MAY2025 · dsbaha/bpi-r4-openwrt-custom
Again, this focuses on stability and usability, not the latest features. So far I’ve had great success in using 802.11ax(e) mode. I do have 120mm fans pointed to these units, too. Peak wifi temp is 59c during periods of high sustained loads. They idle at 37c.
I have a local Gitea server and a local Gitea-runner with a job that’ll compile stuff locally. I can share those a little later. Afterward, I’ll explore just getting Fedora CoreOS or Fedora IOT working here.
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.
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. 
