BpiRouter v1.5.0 Official Version Released and source code on github

Banana Pi Router design BPIRouterOS
1

BpiRouter v1.5.0 Official Version Released ,All corresponding documents are in the GitHub repository.

HSJCTmibsAAGiJJ
HSJCTmibsAAGiJJ1200×569 54.7 KB

based on the latest stable version of OpenWrt: v25.12.5

Supports4 G/5G, Android mobile phone USB shared network, and USB dongle;

Support Hardware:

  • BPI-R4
  • BPI-R4-Lite
  • BPI-R3
  • BPI-R3-Mini
  • OpenWrt One
  • BPI-R4-Pro 8X
  • BPI-R4-Pro 4E

Two ways of multiple WAN ports: defect switching and load balancing;

more please see : Banana Pi Router OS | BananaPi Docs

Supports two types of segmented speed limit control for IoT and guests.

2 Likes
2

Thanks for publishing the source — it was a pleasure to read through.

A few things that stood out for me:

  • the A/B layout with U-Boot bootcount / altbootcmd, and the environment being verified by read-back before a slot switch,
  • RELEASE-INPUTS.lock.json pinning OpenWrt, the feeds and every patch by hash,
  • the installation guide — the exact file per model, and SHA-256 steps for both Linux and Windows,
  • the care in LICENSING.md, e.g. moving the AS21xxx PHY firmware out of vmlinux into a separate package.

A few questions, if I may:

  1. BPI-R4 with 8 GB RAM — the R4 images use the shared -comb BL2, which (as the Pro 8X patch notes) sizes DRAM at 4 GB. Is an 8 GB R4 variant planned, e.g. with the comb-4bg BL2 you already use for the Pro 8X?
  2. Wi-Fi 7 MLO — is multi-link (MLO) configuration planned for the web interface?
  3. NVMe — are there plans to allow installing the system itself to an M.2 NVMe drive (larger root, Docker), in addition to eMMC?
  4. Hardware offload — flow offloading and WED are disabled in v1.5, I assume so that SQM and the Guest/IoT limits stay accurate. Could offload become an option for setups that don’t use shaping?
  5. Pro 8X — boards.sh lists 2.5/5/10 Gbps negotiation and the SFP path as still open. Is there a rough timeline for those?

Also, 989-mtk-eth-defer-notifier-leak.patch looks like it could be useful upstream as well.

Thanks again — looking forward to the final v1.5.

1 Like
3

BpiRouter v1.5.0 Official Version Released ,All corresponding documents are in the GitHub repository.

1 Like
4

I waited a whole year to finally to have Wi-Fi7 and Podkop (now it’ll be Tachion + Zapret Manager) on my BPI-R4 at the same time. But now I want BPI-R4 PRO 8X white with a 10" rack-mount frame.

1 Like
6

Feature request: add a “Services” tab to the BpiRouter web UI

Hello Banana Pi team,

Thank you for BpiRouter. I am running v1.5.0 on a BPI-R4-Pro 4E (installed to eMMC) and I like the interface.

Problem Services that run on the underlying OpenWrt system are not visible anywhere in the BpiRouter UI. To see or manage them I have to switch to LuCI. Because BpiRouter and LuCI should not be used to edit the same settings, it is hard to tell which interface is the right place for a given task.

Request Please add a “Services” (or “Apps”) tab to the BpiRouter UI that:

  1. Lists installed services (init.d scripts) with their status (running/stopped, enabled/disabled at boot).
  2. Allows Start, Stop, Restart and Enable/Disable for each service.
  3. Shows links to the web interface of a service when it has one (including luci-app-* pages).
  4. Optionally, lets the user add custom shortcuts (name, URL or port) so that third-party services appear in the dashboard.

Why it helps

  • Users who install extra packages can see and control them from one place.
  • It reduces the need to open LuCI for routine tasks.
  • It makes BpiRouter more useful as a full replacement for LuCI, not only for the built-in features.

Questions

  • Is there currently a supported way to add third-party packages or custom pages to the BpiRouter UI (for example, an extension point, a config file or a documented way to add menu entries)?
  • If this is planned, is there a target release?

Thank you for your time and for the project.

1 Like
7

Hi, thank you for the detailed request and for using BpiRouter on the R4-Pro 4E.

There is currently no supported extension point or configuration file for adding third-party pages, menu entries or shortcuts to the BpiRouter UI. A Services tab is not currently scheduled, so we cannot provide a target release.

Your suggestion makes sense: having service status, basic controls and application links in one place would make third-party applications easier to use. It would not replace their configuration pages, but it could provide a more convenient entry point.

Managing services and packages today

LuCI remains available at https://192.168.100.1/cgi-bin/luci; substitute your router’s LAN address if you have changed it. Sign in as root with the same administrator password you use for BpiRouter.

  • System → Startup provides basic service controls and boot enable/disable settings.
  • System → Software provides package installation and removal. If a package list update reports an error for a repository named bpirouter, you can ignore it; that entry has no packages on the OpenWrt server.
  • Applications with a corresponding luci-app-* package generally provide their configuration pages within LuCI. Applications with their own web interface are accessed separately.

BpiRouter v1.5.0 is based on OpenWrt 25.12.5. Third-party package installation depends on compatible package sources and dependencies; successful installation does not, by itself, guarantee compatibility with BpiRouter.

In particular:

  • Additional kernel modules must match the firmware’s kernel build exactly. Modules from the standard OpenWrt repositories are built for the standard OpenWrt kernel and generally will not install on BpiRouter.
  • User-installed packages are not automatically carried into the new system slot during a BpiRouter firmware update. Keep a package list and a settings backup, and plan to reinstall compatible packages afterwards. A settings backup does not contain the installed software itself.

Using LuCI without conflicting with BpiRouter

The guidance about conflicting settings does not mean that LuCI must never be used. It means that the same configuration should not be managed through both interfaces.

Use BpiRouter for the features it manages, particularly Multi-WAN and WAN bandwidth shaping. LuCI can remain the configuration interface for third-party applications, provided they do not take over settings managed by BpiRouter.

Avoid stopping or disabling core networking, firewall, management or recovery services, for example network, firewall, dnsmasq, odhcpd, mwan3, sqm and the bpirouter-* services. Applications that modify DNS, routing or firewall settings require particular care, because their changes may conflict with BpiRouter’s own configuration.

We do not currently validate all third-party packages or guarantee their compatibility. If you encounter a problem, please distinguish between an issue within the application and an interaction with BpiRouter. For suspected BpiRouter issues, include the extra packages installed and the steps needed to reproduce the problem.

About a Services page

A Services page with status, basic controls and links to existing application pages (including LuCI) is a reasonable idea. It would need to keep services that BpiRouter manages out of generic start/stop controls, so we want to define its scope before promising a release.

Examples of the services you use would help us prioritise and validate such a feature; we understand that your request is for a general facility, rather than support for only a few named applications.

Thanks again for explaining both the functionality you want and the confusion around which interface should manage it.

2 Likes
8

A more direct answer

To put it simply: the BpiRouter UI cannot pick up third-party packages by itself. Its pages are built specifically for the features we ship. For a package to appear and work properly in the UI, we would have to write BpiRouter pages for that package and test it with the rest of the system. Doing that for every package is not practical, and a generic approach would often be unreliable.

What we prefer is to integrate the packages people actually need, one at a time. We build their settings into the BpiRouter UI and test them properly, so they run reliably and keep working across firmware updates.

If there are specific packages you would like to see in BpiRouter, please tell us which ones and what you use them for. We will use these requests to decide what to integrate first. In the meantime, you can still install and configure them through LuCI as described above.

1 Like
9

Hi, thank you for the detailed explanation. Integrating packages one at a time makes sense to me, so here are the packages I use and what blocks them.

1. Services page / package requests

The applications I would like to see supported are:

For a Services page, what I need most is status, start/stop/enable for these services, and links to their configuration pages (including LuCI), with the services managed by BpiRouter kept out of generic controls, as you described.

2. Kernel options needed to run Tachyon and Forkop

On BpiRouterOS v1.5.0-rc1 (OpenWrt 25.12.5 base, kernel 6.12.94, aarch64_cortex-a53), both Tachyon and Forkop fail to start:

  • Tachyon: Failed to apply tproxy nftables rule (is kmod-nft-tproxy installed?)
  • Forkop: nft refused the ruleset: /dev/stdin:35:98-115: No such file or directory

The cause is that the kernel has no TPROXY and socket support for nftables. modprobe nft_tproxy finds no module, grep -i tproxy /proc/kallsyms is empty, and nft rejects both tproxy and socket transparent expressions. The kmod-nft-tproxy package from the feed installs but is empty (no files). /lib/modules/6.12.94 contains nft_redir, nft_nat, nft_ct and others, but no nft_tproxy, nf_tproxy_* or nft_socket.

Could you enable these options in a future kernel build (as built-in or as modules):

  • CONFIG_NFT_TPROXY
  • CONFIG_NF_TPROXY_IPV4 and CONFIG_NF_TPROXY_IPV6
  • CONFIG_NFT_SOCKET
  • CONFIG_NF_SOCKET_IPV4 and CONFIG_NF_SOCKET_IPV6

These cannot be added from userspace, and modules from the standard OpenWrt repositories will not load because of the vermagic mismatch, so this can only be solved on your side. It would make sing-box based transparent proxy tools usable on BpiRouter. Building kmod-amneziawg for your kernel would cover AmneziaWG as well.

3. Small bug

The bpirouter feed (.../25.12.5/packages/aarch64_cortex-a53/bpirouter/packages.adb) returns a wget error (code 8), which makes apk update fail. Because of this, install scripts such as the AmneziaWG one report “apk failed”. Judging by what I found, this can be worked around by commenting out that line in /etc/apk/repositories.d/, but it would be good to fix it in the firmware.

Thank you for considering this.

P.S. This message was written with the help of an AI (neural network), because I am not very experienced with this topic. I tried to describe the real situation and logs accurately, but if I got any technical terms wrong, please be understanding and feel free to correct me.

10

Hi, thanks for the detailed follow-up. Your diagnosis is accurate, and here are answers to each point.

1. Kernel options for TPROXY / socket

You are right. The current BpiRouterOS kernel is built without TPROXY and socket support for nftables (NFT_TPROXY, NF_TPROXY_IPV4/6, NFT_SOCKET, NF_SOCKET_IPV4/6). These modules must match our kernel build; matching the kernel version number alone is not sufficient, so modules from the standard OpenWrt repositories should not be assumed compatible.

v1.6.0 is already frozen for final testing, so these options can’t be added to it. We plan to include them in v1.6.1. These kernel components will be part of the firmware image and will not need to be installed separately.

This gives sing-box based tools such as Tachyon and Forkop what they need from the kernel. However, these tools manage their own nftables rules and DNS. We have not tested them alongside BpiRouter’s own firewall and per-device DNS management, so we can’t promise full compatibility yet.

2. AmneziaWG

kmod-amneziawg is an out-of-tree kernel module, so it also has to be built for our kernel. Adding it to the Remote access → VPN → Client page is additional UI work on top of that. We have noted it as a request and will evaluate it.

3. Services page

Thanks for listing what you need. A Services page is not on our current roadmap, so we can’t promise it. For now, applications with LuCI configuration pages can be managed there, but avoid changing settings managed by BpiRouter. We have recorded your requirements (status, start/stop/enable, links to each package’s configuration page, with BpiRouter-managed services excluded) for when we review this area.

Separately, selective routing through a VPN (by device first, then by domain) is on our roadmap as a built-in feature, though not for the next releases.

4. The bpirouter feed error

This is a known issue. We found it after v1.6.0 had been frozen for final testing, so it will not be fixed in v1.6.0; it is planned for v1.6.1. Until then, commenting out only the invalid bpirouter line in /etc/apk/repositories.d/distfeeds.list is a safe workaround. This does not uninstall or disable packages already installed. Leave the other repository entries unchanged.

5. Your firmware version

You are on v1.5.0-rc1. We recommend upgrading to the v1.5.0 release, or to v1.6.0 once it is out. Note that the kernel options above are missing in all current versions, so upgrading alone won’t solve the TPROXY issue.

No need to worry about the terminology. Your report was clear and technically correct, and the logs pointed straight at the cause. Thanks again.

1 Like
11

Hi, and thank you for the quick and detailed reply.

I’m glad the kernel options are planned for 1.6.1, and thank you for noting my other requests. I’m really looking forward to the new versions of BpiRouterOS, and I’d be happy to test Tachyon and Forkop once 1.6.1 is out and share the results if that is useful.

Thanks again for your help and for the great work on the firmware.

12

That would be genuinely useful. When 1.6.1 is available, please include the exact firmware version, kernel, installed packages, and relevant logs or reproduction steps so others can compare results. Testing both with and without BpiRouter’s firewall/DNS features would also help clarify compatibility.

1 Like
13