[Discuss] What function are you want BpiRouterOS to support

Banana Pi Router design BPIRouterOS
1

BpiRouterOS is developed based on OpenWrt. Discussions are now underway in the community about the functions you most expect this system to support. We will cooperate in the development.

HSJCTmibsAAGiJJ
HSJCTmibsAAGiJJ1200Ă—569 54.7 KB

BpiRouterOS v1.5.0-rc1 Release Notes:

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

Compared with the previous release version v1.2, this release combines the construction contents originally planned for v1.3, v1.4, and v1.5. The focus has expanded from basic routing configuration to multi-line networking, network isolation, bandwidth management, and multi-board productized delivery, supplementing key capabilities for small offices, stores, and IoT scenarios.

1. Added multi-WAN management, enhancing network flexibility and business continuity.

  1. It supports unified management of multiple internet lines, with configuration of active-standby priority and load balancing weights.
  2. It enables failover to standby lines upon primary line failure, as well as load balancing across multiple lines.
  3. Wired, compatible cellular modules and USB shared networks are incorporated into unified management.

Value: Expanded from single-line internet access to a product with standby network and multi-line scheduling capabilities, reducing reliance on a single broadband, and providing more practical networking options for scenarios such as stores and remote devices.

2. Added cellular and USB backup internet capabilities,

  1. enhancing the management and access capabilities compatible with Quectel 4G/5G modules.
  2. Supports USB Dongle and USB tethering for Android phones.
  3. Added module, SIM, connection status display, as well as fault diagnosis and recovery processing. 4. Completed the centralized sorting and reconstruction of cellular control processes, addressing conflicts among device identification, startup preparation, dialing, and abnormal recovery.

Value: Expanded hardware application scenarios, enabling devices to no longer rely solely on fixed broadband. This part of the work not only involves adding configuration pages, but also requires collaboration among modules, drivers, system network services, and product management logic.

3. Added support for Guest/IoT network segmentation and access control

  1. enabling independent Guest and IoT Wi-Fi networks, with separate configuration of name, password and wireless device binding.
  2. It supports isolation from the main network, and configuration of Internet, internal network access and client isolation rules.
  3. Device management has been expanded from “View List” to allow/deny access, device notes and fixed address binding.
  4. Added DNS filtering and access time period management capabilities.

Value: Separate Guest devices, cameras, smart home devices, etc., from the main office or home network, enhance network management capabilities, and reduce risks caused by mutual access of unrelated devices.

4. New practical bandwidth control features

  1. Guest and IoT networks can respectively set shared upload and download bandwidth caps.
  2. Each WAN can enable bandwidth shaping as needed to improve latency experience during network congestion.
  3. It supports setting different bandwidth parameters per line to adapt to different ISPs and backup lines.
  4. Clarify the combination rules of multiple WAN and bandwidth control to avoid functional conflicts.

Value: Solve the problem that guest downloads or IoT traffic occupies the main business bandwidth, so that limited bandwidth can prioritize serving actual usage needs, rather than simply adding a speed limit page.

5. Upgrade the display of operation status and overall Web experience:

  1. improve the display of network port connection, negotiation rate, line status and device operation status.
  2. Improve continuous sampling and historical curves, distinguishing between normal data, read failures and expired statuses.
  3. Restructure page layout, sidebars, cards and operation buttons, add shadows, animations and mobile adaptation.
  4. Add clear display of BpiRouter product version.

Value: Improve product completeness and on-site diagnosis efficiency, make it easier for users to understand device status, and it is also more suitable for product demonstrations, customer trials and subsequent support.

6. Expand hardware coverage and improve release and delivery.

  1. On the basis of the original six hardware products, add the independent image of R4-Pro 4E, forming 6 product families and 7 SKUs.
  2. Update the basic system version, and complete board-level adaptation and issue handling for R4-Pro switches, PHY, combo-LAN, etc.
  3. Establish a supporting open-source repository, providing build scripts, board-level configurations and matching software packages.
  4. Supplement Chinese and English functional descriptions, installation manuals and installation media for each board model.

7. has carried out reliability rectification on the existing core functions.

  1. This round has also carried out troubleshooting and repair on the effectiveness and rollback of network configuration, VPN, DDNS, backup recovery, factory restoration and firmware management.
  2. The focus is not simply to increase the number of functions, but to deal with the consistency of behavior when multiple functions are enabled at the same time, configuration failure, device restart and network exception. Work covers front-end, back-end, system services, board-level drivers, build releases, and user documentation.

Summary

Core progress of v1.5 is that BpiRouter has further developed the complete product capabilities of “multi-line access, partition management, bandwidth control and multi-model delivery” from the previous state of “configurable and internet-accessible”. This update not only adds user-visible features, but also completes a large number of underlying adaptation, exception handling and delivery construction to support these functions.

about BpiRouterOS ： Banana Pi Router OS | BananaPi Docs

2

I just hope that BpiRouterOS will be based on OWRT 25 will include drivers for your Wi-Fi7 card.

1 Like
3

functions you most expect this system to support.

best functions would be commits in git, so modifications can be easily dissected :slight_smile:

1 Like
4

This time it is based on the latest stable version of OpenWrt: v25.12.5

1 Like
5

My main concerns:

  1. bpirouter-ui-1.5.0_rc1-r1.apk . apid starts uci and ubus as child processes. The ubus package in the binary wraps the command-line tools (ShellOutput, UCIBatch, RunTC, …). It does not use the ubus socket. This means:
  • a new process for each call
  • text output that must be parsed, which breaks on format changes or unusual values
  • command injection risk if any UI value is not escaped
  • only exit codes as errors
  • races with LuCI, hotplug scripts and SSH usersrpcd already serves ubus as JSON-RPC on loopback, including the uci object with apply/confirm/rollback. With net/http from the Go standard library you could use it without cgo, and drop the process calls and the text parsing.
  1. apid rebuilds what rpcd already has. That includes JWT auth next to rpcd sessions and ACLs, and commitconfirm next to rpcd’s apply/confirm. The result is two admin interfaces (your UI and LuCI at /cgi-bin/luci) with two login systems. The two can also make conflicting config changes.
  2. The Go toolchain is out of support. apid is built with Go 1.22.2 (April 2024), which no longer gets security fixes, and it runs as root. Because go.mod declares an old Go version, the binary also gets weak TLS defaults (tls10server=1, tlsrsakex=1). nginx terminates TLS, so this has little effect today, but it shows the version is stale.
  3. The management layer is closed. The UI and apid ship only as a prebuilt package. Users cannot audit, patch or rebuild the part that runs as root and controls the network. For router enthusiasts, I think this is the most important problem.
  4. Test and debug files ship in the package. The acceptance scripts (/usr/share/bpirouter/acceptance/*.sh) bind-mount over /sbin/uci and /bin/ubus to inject faults. They should not be in a release package.
  5. Patches are not sent upstream. These could be accepted upstream: R4-Pro board support, the netifd lifetime and IPv6 fixes, the mwan3 route cleanup and the uqmi APN fix. These need a root-cause fix first: the 3 “DO-NOT-SUBMIT” MxL862xx patches, the AS21xxx PHY workarounds, and 001-mt76-disable-wed, which turns off Wi-Fi offload for all users.

I will not use BpiRouterOS as it is. My main reasons are the closed root daemon and the process-based uci/ubus access. I will stay on vanilla OpenWrt with LuCI. The open parts are useful, and I would be glad to see them upstream, mainly the A/B boot work and the R4-Pro support.

If you open-source apid or move it to rpcd over loopback, I will review it again.

2 Likes
6

Yes. The v1.5.0-rc1 images for the BPI-R4, R4 Pro and R4 Lite already include the MediaTek Wi-Fi 7 driver (mt7996e) and the firmware for the BPI-R4-NIC-BE14 card, and the driver loads automatically at boot. With the card fitted, the web UI shows its 2.4 / 5 / 6 GHz radios. 6 GHz and channel availability depend on the country setting and on client support.

Note that Wi-Fi 7 MLO (multi-link operation) is not supported in this release.

1 Like
7

@yagop Thank you for the detailed review of the RC1 package. We reviewed the RC1 artifact and the relevant implementation.

Two release issues we will address before v1.5 stable

  • Acceptance scripts: The fault-injection scripts under /usr/share/bpirouter/acceptance/ should not ship in normal release images. They are not run automatically, but we will remove them from the release package and retain them for development testing.
  • Go toolchain: You are correct that RC1’s apid was built with Go 1.22.2, which is out of support. We will move to a supported Go toolchain and update the go.mod version, with regression testing. The legacy TLS compatibility settings are present in the binary. The management HTTPS endpoint, however, is terminated by nginx, configured for TLS 1.2/1.3; apid itself serves HTTP on 127.0.0.1:8080. That limits the relevance of those TLS defaults to the current deployment, but does not remove the need to update the toolchain.

CLI access, error handling and configuration conflicts

apid invokes the uci and ubus executables rather than connecting directly to the ubus socket. This introduces process-creation overhead, which direct integration could reduce.

There are some distinctions worth clarifying:

  • The main UCI/ubus calls pass arguments directly to the executable, without shell interpretation. Shell metacharacters in those arguments therefore do not automatically become commands.
  • ubus call responses are decoded as JSON. Other operations, including some UCI and system-command output, do require text parsing.
  • For ubus calls and UCI batch operations, error handling is not limited to exit codes. ubus calls also handle timeouts, cancellation and JSON decoding failures. The UCI batch path checks stderr because unsuccessful batch operations do not always produce a nonzero exit status.

Some sh -c paths remain and require careful validation; direct argument passing in the main UCI/ubus calls does not establish the safety of every command path. For uci batch, values are checked centrally before the batch text is built: any value containing whitespace, quotes, backslashes, # or control characters is applied through a separate uci set invocation instead. Reducing shell interpolation and batch-text construction would further reduce reliance on validation.

Your suggestion to use rpcd through an HTTP-to-ubus bridge is technically reasonable and can be implemented without cgo. We have not committed to that migration. There is overlap with our authentication and configuration-apply handling, but replacing those parts requires comparing their behavior, including recovery and service operations.

The external-writer concern is valid. LuCI is retained for users who prefer it and for advanced configuration, but it is not a fully equivalent alternative: some product-managed features, such as multi-WAN and SQM, are managed only through our interface, and changes made to them elsewhere may be normalized by the product. apid’s internal coordination does not serialize arbitrary changes made through LuCI, SSH or other scripts. Concurrent edits to the same settings through different interfaces are not coordinated and should be avoided. Moving calls to rpcd would not, by itself, eliminate all such conflicts.

Source availability

We are not opening the source of the UI and apid at this time. We understand that this is the main reason you will stay on vanilla OpenWrt, and that is a reasonable choice. We would still welcome further feedback from you; reviews like this one help us improve.

Patch origins and WED

A few points need clarification:

  • The three MxL862xx DO-NOT-SUBMIT patches were copied unchanged from OpenWrt main at commit 93cf01b. Several AS21xxx patches are also upstream-authored, alongside our local adaptations. Their origin does not remove the underlying limitations, and being carried by OpenWrt does not mean they have been accepted into mainline Linux.
  • In the mt76 revision used by OpenWrt 25.12.5, wed_enable defaults to false for both relevant drivers, and the unmodified mt76 package Makefile does not override it. 001-mt76-disable-wed explicitly preserves that setting. Keeping WED disabled is an explicit v1.5 product policy.
  • OpenWrt main now includes R4-Pro 8X and 4E support. Our integration targets 25.12.5 and contains backported components and local changes; it should not be described as identical to current main.

We agree that reusable fixes are worth contributing upstream. The netifd, mwan3 and uqmi changes need comparison with current upstream implementations to determine which are suitable for upstream submission.

Thank you again for the concrete findings and for recognising the A/B boot and R4-Pro work.

1 Like