Please, let them hire you and show them how to do things right. Before they start manufacturing the much-promised 3rd generation Be14000 and the famous Be19000 cards again, tell them how to manufacture them, since their engineers have proven themselves inadequate for both routers and cards. Before releasing something useless again, they should show you all the documentation, because I’m sure you’ll teach them how to do a good job.
First, your flowers. Marvelous work, you’ve done what even Gli.Net can’t do with their own products which is bring the latest (Main release) OpenWRT Firmware to a custom, powerful router. I thank you very much for bringing this to us.
As for my issue I am having, I have the BPI-R4-Pro-8X with the Wi-Fi 7 Module, and I cannot get Wi-Fi to work. I installed your release titled “BPI-R4 Pro 8X standard WiFi (latest)” as that seemed like the only one for my router. Nearly everything else works without an issue, I even got the Cellular Modem working once I installed the luci-proto-modemmanager, something I couldn’t get with the other firmware’s. What do I need to do for the Wi-Fi? Here are screenshots and the wifi manager log:
I went through your syslog. If you installed exactly this release:
then this is not a bug in the image/release — I verified Wi-Fi works on a real BPI-R4 Pro 8X with a BE14 Wi-Fi card on this exact build.
The log shows the MT7996 radio never appears on the PCIe bus (PCIe link down, no mt7996 device → no radio; the Wi-Fi-manager error is just a side effect of that). So the card isn’t coming up at the hardware level — almost certainly one of:
The Wi-Fi card has no power. The BPI Wi-Fi NIC needs a 12V supply, enabled by the on-board SW4 switch — it must be in the ON position (the 12V LED lights up when on). This is by far the most likely cause of exactly this symptom.
Flip SW4 to ON, power-cycle, and Wi-Fi should enumerate. If SW4 is already ON and the 12V LED is lit, reseat the card; if it still doesn’t show up, the module itself is suspect
Thanks, you were right, Don’t know how I missed this in the getting started instructions. Thank you again, I will look to see about getting the port activity working as on the overview page, all show disconnected and it doesn’t have all the ports on the device listed. It’s been a while since I did any work on stuff like that (Dynalink Router), think it’s just a file edit somewhere, when I get a sec, if I find it, will share here.
I’m currently using your BPi-R4 Pro 8X wired build, and I must say I’m really impressed with the performance and stability – thank you for your great work on this project!
I am now at the point where I would like to expand my setup. I am considering recompiling the system in my own build environment to add some custom packages and maintain full control over the build. However, I’ve hit a roadblock with integrating a custom kernel patch.
I need to include an SFP quirk for my ODI DFP-34X-2IY3 and HALNy HL-GSFP modules to force 2.5G speed, as the standard quirks are not sufficient for my specific link. I have a prepared patch file, but I’m struggling to inject it properly into your builder workflow without breaking the dependency management (I encountered issues with missing mtk-feeds-cache during the process).
What is the recommended “best practice” in your opinion for injecting custom patches and adding extra packages while using your builder scripts? Is there a specific directory structure I should follow to ensure the builder auto-applies my patches, or should I take a different approach?
I would appreciate any guidance or tips on how to handle this correctly.
Thanks a lot for everything, Wozi.
Thank you, Xiaomi_ax3600, for your help earlier—you guys are the best!
Thanks a lot for the kind words — really glad the Pro 8X wired build is treating you well!
First: update your builder.
Before anything else, grab the latest builder for your variant — builder-pro-8x-wired.sh from the pro-8x-unifi branch. We recently changed how the MTK feed is pulled: the current builder clones the MTK feed at a pinned commit automatically instead of relying on a local repo-cache tarball, which we removed. Your missing mtk-feeds-cache error is almost certainly because you’re on an older builder that still expects that tarball — updating should clear it up on its own, since the feed gets fetched for you.
Injecting your SFP quirk.
The builder doesn’t auto-scan a folder — each patch is copied explicitly, and a kernel patch has to land inside the MTK feed overlay, otherwise the feed-copy step overwrites it. Two steps:
Drop your patch in my_files/, e.g. my_files/999-sfp-12-odi-halny-2g5.patch (use a 999- prefix so it applies after the stock quirks).
Add one line to the builder, right next to the existing SFP quirk lines:
That’s exactly how the existing SFP quirks are wired (999-sfp-10-additional-quirks.patch, 999-sfp-11-...) — your change is the same kind, so use one of those as a template. OpenWrt then auto-applies everything in patches-6.12/ via quilt during the kernel prepare step.
Key point: copy into mtk-openwrt-feeds/.../files/target/linux/..., not straight into openwrt/target/... — the feed lays its files/ overlay on top of the tree and would clobber a patch placed there directly.
Custom packages.
Add them next to the other config lines (echo "CONFIG_PACKAGE_yourpkg=y" >> .config, then ./scripts/feeds install yourpkg). We’re also planning to publish a prebuilt OpenWrt SDK for this target soon — the cleaner route when you only want extra packages, with no full-tree rebuild. I’ll post once it’s up.
One favour, if you’re up for it:
Send over your ODI DFP-34X-2IY3 / HALNy HL-GSFP 2.5G quirk once it works. Module quirks like that are useful to others, and I’d happily fold it into the build so it works out of the box for everyone with those modules.
Hope that unblocks you — shout if anything else comes up.
