Banana Pi official Router UI design

Banana Pi Router design BPIRouterOS
1

we now design a Banana Pi Office Router UI, Base on OpenWrt . any good idea?

#openwrt #router #wifi #router #bananapi #opensource #Mediatek #OEM #ODM

1 Like
2

instead of writing another UI (we already have a bunch of them with openwrt), why not focus the time and effort on things that people really need like the firmware files for the switch, be19 etc.?

4 Likes
3

! standing ovation !

1 Like
4

BE14 without too much noise?

1 Like
5

Any news on the MaxLinear switch chip firmware?

6

I agree. Stick to OpenWRT and extend hardware support via driver development and bug fixes. Open-source any closed binary blobs too, if possible.

One reason I switched from GL-Inet devices to the OpenWRT One made by BPi is that I wanted pure OpenWRT and not GL-Inet’s additions/modifications.

1 Like
7

The BPI‑R4 PRO community does not need another web UI. We already have LuCI and plenty of alternatives. What blocks real-world usage are fundamentals that still aren’t delivered officially in a reproducible way.

  1. Switch/PHY (MaxLinear) firmware + clear distribution terms Without the required firmware and clear documentation (what can be redistributed, what is NDA-restricted, where to obtain it), the switch remains a bottleneck. This should be treated as priority #1, ahead of cosmetic UI work.

  2. Upstream drivers/DSA work + official reproducible builds Right now the platform depends too heavily on community forks and community builds. If this device is meant to be taken seriously:

The important work (drivers/DSA/quirks) should be upstreamed, with a clear status for anything that cannot be upstreamed. There should be an official reproducible build tree and public CI producing regularly updated reference images with verifiable commits/artifacts. 3) Stability/QA focus instead of announcements There are recurring reports of low-level issues (INA2xx I2C errors, MaxLinear MMD write failures, MT7996 probe timeouts). Even if some units are defective, the repeated pattern suggests QA/troubleshooting/mitigations need improvement. Announcing “a new UI” while this persists sends the wrong message.

  1. A real roadmap (dates) “Soon” is not a roadmap. At minimum, publish:

calibration start/end shielding/heatsink finalization first production batch / approximate first sale date This is no longer a cheap experiment: pricing has escalated from ~€150 to ~€325. Without a stable baseline, official CI builds, and at least a minimal schedule, you’re effectively asking users to pay a premium and also act as QA.

  1. If there are NDA constraints, say so clearly But then compensate with:

regularly updated reference images (CI), an explicit list of what is open vs closed, clear instructions for reproducible builds.

2 Likes
8

your ideas are very great. we will follow them and make more better.

1 Like
9

BpiRouterOS have update image. welcome to test it.

10

BPI-R4 4G image is still dated 2026-06-29

Did you update only specific models?

11

Hello,

  1. Please publish the source code.
  2. When do you plan to support the Banana Pi BPI-R4 Pro (4E)?
12

This system is likely not open source.

13

Hey @hyf,

I suppose it is (see screenshot), therefore sourcecode is required to be published to avoid to be sued for GPL violations.

image
image1939Ă—1407 135 KB

14

who should sue someone in china? they dont care.

15

Sure, china may be excluded of legal actions … but there may be import bans for BPI in some important WTO countries. How? Successful actions - some lead by https://gpl-violations.org.

Besides of that the OpenWRT codebase in official repos may could loose the BPI device configs if OpenWRT mainline devs decide to force future GPL compliance …