The Cavium CN6640-SNIC10E is a dual-port 10GbE PCIe card that shows up on eBay for ~$15–20. It's an OEM "SmartNIC," an 8-core Octeon II SoC meant to run Cavium's vendor LiquidIO firmware. Problem: the stock liquidio driver basically doesn't work with these OEM boards (its flash-handshake boot model doesn't match), and secondhand cards tend to have bootloaders in a rough state. There's a good writeup of people hitting a wall on this back in 2021 on the OpenWrt forums. Both PCIe BARs would read back all-0xFF and the board looked architecturally dead as anything but LiquidIO.

Turns out that "BAR wall" is just unprogrammed PEM inbound registers, not a hardware limit. You can program them from the card side with plain u-boot write64 (no firmware needed) and open a full bidirectional PCIe channel.

On top of that I built:

- an OpenWrt image that runs on the card from RAM (nothing flashed, fully reversible)

- a reverse-engineered PCIe BAR2 shared-memory datapath between host and card

- an out-of-tree host kernel module (octnic) that registers the card as two independent Linux NICs, oct0/oct1

Result: line-rate 10GbE, TX at 9.7–9.8 Gb/s (zero-copy), RX at 8.1–8.8 Gb/s (DMA via the Octeon DPI engine), both ports live simultaneously on a DAC. Boots with no serial cable after a one-time provisioning step. A systemd service brings both NICs up automatically at boot, so day to day it's just a normal 10GbE card as far as the rest of the homelab is concerned.

No vendor NDA firmware anywhere in the stack, host OS untouched, and the whole thing is undoable if you want the card back to stock.

Repo (driver, boot tooling, docs): https://github.com/nicologiuliani6/cavium-cn6640-snic10e-octeon-ii-nic

Docs cover architecture, first-time flashing/provisioning over serial, usage, and full performance numbers if anyone wants to reproduce this on their own card.

Happy to answer questions. This took a fair bit of reverse engineering to get past the BAR wall so ask away if you're stuck on one of these boards.

If you want to help out (test on your own board, contribute code, whatever) open an issue or discussion on the repo. If you'd like to support the project, GitHub Sponsors is enabled there too.

UPDATE: new idea, Another interesting use case is running OpenWrt standalone directly on the card.

For around $13, you basically get a dual-port 10GbE SFP+ router, without needing a separate x86 machine. And with two or more of these, you could potentially build a pretty cheap multi-router failover setup.

That's actually one of the things I'd like to explore next.

​

Hi,

I'm running  OpenWrt 24.10.0 (flippy build, kernel 6.1.115) on a Radxa E24C board with RK3528 SoC and RTL8367B switch. I have a dual-WAN setup with mwan3 for load balancing, but throughput is capped at ~300 Mbps. I've done extensive testing and identified the root cause. I'm sharing my findings below in case they're useful for the community or if there's a solution I'm missing.

---

## 1. Hardware Setup

- **SoC:** Rockchip RK3528 (4× Cortex-A53 @ 2.0 GHz max)

- **Switch:** Realtek RTL8367B (4× GbE ports)

- **NIC driver:** stmmac (Synopsys DWMAC4/5, `st_gmac` module)

- **RAM:** 1 GB

- **Storage:** NVMe Intel 128 GB

### Switch Port Mapping (confirmed via testing)

| Port | VLAN | Interface | Role |

|------|------|-----------|------|

| 0 | VLAN 3 | eth0.3 → wan2 | WAN2 (second modem, 600 Mbps) |

| 1 | VLAN 1 | br-lan | LAN (PC connected) |

| 2 | VLAN 1 | br-lan | LAN (free) |

| 3 | VLAN 2 | eth0.2 → wan | WAN1 (main modem, 1000 Mbps) |

| 6 | — | CPU (internal) | SoC uplink |

### Current NIC Configuration

```

Driver: st_gmac (Synopsys DWMAC4/5)

RGMII link speed: 1000 Mbps (between stmmac and RTL8367B)

Queues: RX=1, TX=1 (single-queue hardware)

TSO: enabled in dmesg but tx_tso_frames=0 (not actually offloading)

RPS on eth0: 0xd (CPUs 0,2,3) ✓

RPS on eth0.2: 0x0 (disabled) ✗

RPS on eth0.3: 0x0 (disabled) ✗

Ring buffer: 1024 (max)

IRQ 55 (eth0): on CPU0, affinity 0-3

IRQ 56 (eth0): 0 interrupts (unused)

```

---

## 2. Software Configuration

- **mwan3:** Load balancing with weighted policy (5:3 ratio for 1000:600 Mbps links)

- **AdGuard Home:** DNS filtering on port 53

- **Firewall:** iptables (fw3), WAN REJECT policy

- **CPU governor:** schedutil (scales frequency with load)

- **Swap:** zram 512 MB (zstd) + swapfile 4 GB on NVMe

- **TCP:** BBR congestion control, fq_codel qdisc

---

## 3. The Problem

With both WANs active and mwan3 load balancing, throughput is capped at **~300 Mbps** aggregate. The expected combined throughput should be ~1600 Mbps (1000 + 600). Individual links can reach their full speed when tested alone (without mwan3), but with mwan3 active, the aggregate drops to ~300 Mbps.

---

## 4. Root Cause Analysis

### 4.1 Confirmed: Flow Offloading (SFE and xt_FLOWOFFLOAD) Breaks mwan3

I tested two different offloading mechanisms, and **both** caused mwan3 to enter "error" state:

**Test 1 — SFE (Shortcut Forwarding Engine):**

- Module: `kmod-shortcut-fe` + `kmod-shortcut-fe-cm` (compiled into kernel, `CONFIG_SHORTCUT_FE=y`)

- Result: mwan3 went to "error" state, network lost connectivity

- Had to disable SFE and restart mwan3 to restore

**Test 2 — xt_FLOWOFFLOAD (iptables flow offload):**

- Module: `xt_FLOWOFFLOAD` (loaded but inactive, `flow_offloading='0'`)

- Enabled via: `uci set firewall.@defaults[0].flow_offloading='1'` + firewall restart

- Result: mwan3 went to "error" state on both WAN interfaces

- Internet still worked on individual interfaces (ping via eth0.3 succeeded), but mwan3 tracking probes failed

- Had to restore firewall backup and restart mwan3 to restore

### 4.2 Why Flow Offloading Conflicts with mwan3

**mwan3** works by:

1. Marking packets in the `mangle` PREROUTING chain (`iptables -m mark --set-mark`)

2. Using `ip rule fwmark` for policy-based routing (selects WAN based on mark)

3. The routing decision determines the outgoing interface per-connection

**Flow offloading** (both SFE and xt_FLOWOFFLOAD) works by:

1. Caching the resolved route for established flows (including the output device)

2. Subsequent packets in the flow bypass conntrack, iptables, and routing — they're fast-pathed directly to the cached device

**The conflict:** Flow offloading bypasses the iptables mangle chain where mwan3 marks packets. Even though the first packet of a flow goes through the full path (mark → route → NAT), the flow offload entry caches the route. When mwan3's tracking probes (ICMP) are sent, they may be affected by the firewall restart or chain reordering, causing the tracking to fail.

Additionally, when the firewall is restarted (required to apply flow offloading changes), mwan3's iptables rules are temporarily removed and re-added. During this window, tracking probes fail and mwan3 marks the interfaces as "error".

### 4.3 Software NAT Bottleneck

Without any offloading, every packet goes through the full path:

1. conntrack lookup (hash-based, O(1))

2. iptables mangle (mwan3 mark processing)

3. Routing decision (policy routing via ip rule)

4. NAT rewriting (MASQUERADE/SNAT)

5. Forwarding to outgoing interface

On the RK3528 (Cortex-A53 @ 1.4–2.0 GHz), this path is CPU-bound. The single-queue NIC means the TX path (NAT rewriting) is single-threaded, limiting throughput to ~300 Mbps.

### 4.4 Additional Bottlenecks Found

| Issue | Status | Impact |

|-------|--------|--------|

| VLAN interfaces (eth0.2, eth0.3) have RPS=0 | Confirmed | RX processing not distributed across CPUs for VLAN traffic |

| TSO enabled but tx_tso_frames=0 | Confirmed | TCP segmentation not offloaded to NIC — CPU does all segmentation |

| RGMII link = 1 Gbps | Confirmed | Total aggregate throughput for all ports limited to 1 Gbps |

| CPU at 1416 MHz (not max 2016 MHz) | Confirmed | schedutil scales down — may not ramp up fast enough during burst |

| Single queue (RX=1, TX=1) | Confirmed | No multi-queue parallelism |

---

## 5. What Was NOT Tested (Due to Risk)

- **nftables flowtable** (`CONFIG_NFT_FLOW_OFFLOAD=m`): Likely has the same conflict as xt_FLOWOFFLOAD since both use the nf_flow_table infrastructure

- **Hardware NAT** (`flow_offloading_hw='1'`): RK3528 does not have a hardware packet processing engine (PPE), so this would fall back to software anyway

- **Bonding (LACP/LACP):** Requires ISP-side support, not applicable for two different ISPs

---

## 6. Questions for Support

1. **Is there a way to make flow offloading work with mwan3?** Specifically, can we configure xt_FLOWOFFLOAD or nftables flowtable to only offload AFTER mwan3 has marked and routed the packet, without interfering with tracking probes?

2. **Can the stmmac driver be configured for multi-queue?** The hardware reports `RX: 1, TX: 1` max queues. Is there a way to enable more DMA channels on RK3528?

3. **Why is TSO not working?** TSO is enabled in dmesg (`TSO feature enabled`) but `tx_tso_frames=0`. Is there a driver or firmware issue?

4. **Is there a way to increase the RGMII link speed?** The current link is 1 Gbps. Some RK3528 variants support RGMII at 2.5 Gbps. Is this configurable via device tree?

5. **Are there any kernel patches or driver modifications** that could improve single-queue NAT throughput on this hardware?

---

## 7. Current Working Configuration

The system is currently stable with:

- Flow offloading: **disabled** (`flow_offloading='0'`)

- SFE: **disabled** (module loaded but not active)

- mwan3: **active** (load balancing 5:3)

- Throughput: **~300 Mbps** aggregate

- Both WANs functional with failover

---

## 8. Summary

| Metric | Value |

|--------|-------|

| Hardware | RK3528 + RTL8367B |

| OpenWrt | 24.10.0 (flippy), kernel 6.1.115 |

| NIC driver | stmmac (single queue) |

| RGMII speed | 1 Gbps |

| Flow offloading | Confirmed broken with mwan3 (both SFE and xt_FLOWOFFLOAD) |

| Current throughput | ~300 Mbps aggregate |

| Expected throughput | ~1600 Mbps (1000 + 600) |

I appreciate any guidance or suggestions. Thank you for your time.

Best regards,

I know that not everybody checks out the OpenWRT forums, and that is a shame really. For those who are interested, and haven't moseyed over there for a gander, there has been a lot of work to bring Mainline OpenWRT to WiFi 7 devices lately.

The furthest along one currently is the GL.iNet Flint 3 (GL‑BE6500) linked below
https://forum.openwrt.org/t/gl-inet-flint-3-exploration-gl-be9300-ipq5332/250267

I have recently picked up the mantel of working on the Cudy AP11000 which can be found
https://forum.openwrt.org/t/installing-openwrt-on-cudy-ap11000/240369

That being said, what features and desires do the lovely OpenWRT community look for in WiFi 7 devices?

Hi everyone,

I have a ZTE ZXHN H188A/H288A (same hardware and software, different names) and I’m interested in getting OpenWrt running on it. I opened the device and extracted the following hardware information:

Detailed Specs In Googel Docs

Google Drive Link For All Modem’s Files Obtained Via FTP

Google Drive Link For High-res Motherboard Photos

The PCB is clearly marked ZXHN H288AV1.1.

I haven’t flashed anything yet. I’m willing to provide UART boot logs, firmware dumps, partition information, and test OpenWrt builds on this hardware.

Does anyone know if this device/platform is already supported, or if there is an existing EN751627/OpenWrt port that could be adapted?

Photos of the PCB attached. Any help from OpenWrt developers would be greatly appreciated!

Thanks to the community. I am getting 30-35 MB/s writes on the sandisk USB 3.0 flash drive and happy with it.

Hi, I am currently looking to replace my Turris Omnia with a more powerful option for my main router/gateway.

I want two sfp+ port and ideally one 2.5GBE.

I have considered banana pi r4 pro but seems overpriced. I have considered Ubiquiti UCG Fiber but would prefer remaining Open Source. Specialized mini-pc looks overpriced as soon as you start including RAM and storage.

For now the best value seems to be Lenovo m720q 150-250€ (depending of the RAM amount) but will need to find pcie riser and right card.

Any other option to consider?

I live in France if that matters.

Title says it all.

On my old TP-Link Archer C50 router, I go to 'DHCP Settings' and it's right the heck there - see attached. You fill in your DNS and your secondary DNS and click 'Save'. DONE....EASY.

How, on OpenWRT....can I just add Google's DNS servers in the same manner? I've read so many articles and posts about it, but every single one seems to contain different information...?

This is the last hurdle I'm having before I replace said old Archer with a LinkSYS WRT1900AC running OpenWRT that I picked up for cheap.

Thanks so much for the help!

Apparently I won't get full 802.11ac, no beamforming, and limited tri-band speed because it uses Broadcom BCM43602. I pretty much only use WiFi, I assume it's not worth the upgrade? It says it's supported, but am I correct with what I'm saying?

I need to install VPN to any of those routers. I had AX50 before and bought C6U for the sake of OpenWRT.

I've tried installing mihomo/Nikki and sing-box-tiny but they were really laggy and I don't really understand the reason behind it.

Is there any better way to solve this? Do I return C6U while I still can?

Edit: here’s the actual specs I obtained so far:
SoC: MediaTek/EcoNet EN751627, MIPS 1004Kc, 900 MHz
* RAM: 128 MB
* Flash: 128 MB SPI NAND (HeYangTek HYF1GQ4UDACAE)
* 2.4 GHz: MediaTek MT7603EN, 2x2
* 5 GHz: MediaTek MT7612EN, 2x2 802.11ac
* Ethernet: 4× Gigabit LAN + 1× WAN
* DSL: EcoNet EN7556N line driver
* VoIP: 2× FXS
* USB: 1× USB 2.0
* UART: Unpopulated 4-pin header, apparently connected to ttyS0
* Firmware: Dual-bank A/B layout with separate kernel/rootfs partitions

Actual ftp files from the modem itself:

https://drive.google.com/drive/folders/1AjXJRn7XsKcQGdAc9dWQ4g2I17xgbG4_

High-res Motherboard photos: https://drive.google.com/drive/folders/1SEecEH4HexAqZiC7v0f1l7hQwSTN3IJz

ZTE H188A V2 is highly capable of running OpenWrt. Why is there no build for it?
The ZTE H188A V2 is a very common and, from what I can tell, highly capable modem/router. In Egypt alone, it has been widely distributed by all four major ISPs: WE, Orange, Etisalat, and Vodafone. I see this router everywhere, so I wouldn’t be surprised if there are thousands—or potentially millions—of units in use.
I’m wondering why the H188A V2 isn’t supported by OpenWrt yet, especially considering the hardware it has.

The biggest problem with the ISP firmware for me is bufferbloat and the lack of proper QoS controls. I tested OpenWrt in a virtual machine on my laptop and installed SQM (Smart Queue Management). The difference was incredible. My bufferbloat results improved dramatically, which made me really want to run OpenWrt directly on the router.

The hardware also seems more than capable. As far as I know, it has 128 MB RAM and 128 MB flash (please correct me if I’m mistaken), along with what seems to be very decent hardware overall. The router itself has also proven to be reliable and has good longevity.

This is becoming more relevant in Egypt because we’re increasingly moving toward fiber connections. If these routers can’t run better firmware, I worry that a huge number of perfectly good H188A V2 units will eventually be thrown away and replaced, simply because the stock firmware is so limited.

What’s especially interesting to me is that other ZTE models, such as the H108, have OpenWrt support, while the H188A V2 doesn’t. So I’m curious: what is preventing support for the H188A V2?
I actually have an H188A V2 with me right now, and I’m willing to help with development/testing.

I can:

Open the router and provide high-resolution photos of the PCB and components
Provide information about the hardware/chips
SSH into the device

Provide a full software/firmware dump, if useful
Run commands/tests requested by developers
Provide any other information needed to investigate the platform

If someone is interested in trying to bring OpenWrt to this router, please let me know what information you need. I’d be happy to provide whatever I can.
Given how widely this router is deployed in Egypt, I genuinely think OpenWrt support could benefit a very large number of users. We could potentially continue using this hardware with our new fiber connections instead of throwing perfectly good routers away.

So, developers: is there a specific hardware, bootloader, driver, or firmware issue preventing OpenWrt support for the H188A V2? And what would you need from me to investigate it?

Downloads.openwrt.org got banned in my country, so I now have to use a mirror (which can be banned too) or a proxy. I need help with the latter. Is there a way to configure it to send requests through a proxy, like it's possible with apt?

I did search before posting, but I didn't find much, and what I've found (less-convenient solutions) doesn't even work.

UPD: Solved. Requires wget-ssl (not installed by default).

https_proxy=http://proxy.example.com apk <whatever>

Can someone please tell me with specific steps to set up my GL.iNet router to block DoT and DoQ?

Hello everyone im new in OpenWRT so far i did flash OpenWrt 25.12.2 r32802-f505120278 to my AX23 1.20. I've done my research thru AI and said that i can do Dual wan setup with failover and load balancing with this kind of router. Appreciate if someone did it already and am i already in correct openwrt version ? If you guys have any resources please do share it. Thank you !

I don't know, maybe I'm getting hyped by their videos, but every time I see their releases I think "damn, this is so powerful and polished". But so is OpenWrt, right? At least on the feature side of things. What we're missing on OpenWrt is just the fancy UI when compared with Ubiquiti?

The subject pretty much asks it...

The latest post I found in a search was this one: https://www.reddit.com/r/openwrt/comments/1oju4ah/how_do_you_actually_expand_to_the_entire_drive/

It's been 10 months and we have a new major version stable release. Is it possible to safely expand the partitions now, or is it still a problem?

Hi, Who are the admins over on the forums? They seriously need to deal with certain users. I shouldn't be given vauge answers time after time, and attacked for asking a serious question about adding hardware support. If you don't have nothing useful to add don't comment. Ok, rant over.

So I noticed that on the Attended Sysupgrade config page on luci you can switch the server and once I do that I can see the different versions available. So my question is, is this safe and has anyone tried it with success? I'm pretty new to openwrt/immortalwrt came from ddwrt which is drastically different.

immortalwrt as i understand it is simply openwrt with a few extra pkgs included automatically. If its just a few extra packages and settings are saved when doing the sysupgrade, the logic stands that it should just work, right?

Is it possible to block port 853, which is what DoT and DoQ use? Then force all traffic to use the DNS settings of the OpenWRT router?

Has anyone compiled a list of DoH servers that is safe to block? How do I add the DoH server list to OpenWRT?

Can port 53 also be blocked, or is it required for internet access?

I actually posted something on r/TPLink_Omada already but I wanted to ask on this sub regardless.

I bought the TP-Link EAP245 v3 because it had 2 ports and some other posts on Reddit said it should be bridged with the original firmware. Good if you don't have the space for a network switch.

To my suprise I can't seem to get a good connection from the second port. For testing I connected a laptop to ETH2 and got an IP, but I can't get internet. After some digging I found that DHCP and pinging Internal & External IPs works but DNS and other services (HTTP etc) won't work. Windows and Linux show the same synthoms.

Bla bla. While digging for info I found out that OpenWRT actually supports (or partly supports) the EAP245 (https://openwrt.org/toh/tp-link/eap245_v3). Does someone of you run this AP with OpenWRT installed and maybe has the resources to test running with daisy-chaining?

I'm not a fan of flashing OpenWRT to it, voiding a potential warrenty, before knowing if OpenWRT could fix the issue. The wiki page provided pictures of the inside of the device. Both ETH ports are connected to an Qualcomm Ethernet 7P-switch chip (QCA8337N-AL3C), so it seems it should work or it could be configured via TP-Link or OpenWRT.

Anyhow, thank you for your help and I hope even if this isn't resolvable, it still helped someone like me, buying the EAP for daisy-chaining.

(Also: Mods, if there is anything wrong with my post, please let me know)

One of the reason I got some glinet devices is the access to their cloud. Does anybody know, is there already some addon to OpenWRT to add the cloud access to OpenWRT instead of having a glinet firmware?

e.g. strip device dependend token from the device, install OpenWRT and add the token for cloud access?

Hi everyone,

I’m using QoSMate on OpenWrt and noticed that under Manual DSCP Tagging, I only get these DSCP options:

EF, CS5, CS4, CS6, CS7, AF41, AF42, AF11, CS2, CS1, CS0

Is this normal? Do you guys also see only these DSCP values in QoSMate, or should there be more options available?

I’m specifically wondering if this is limited by QoSMate itself, the OpenWrt version, or the configuration.

Running OpenWrt 24.10.5.

Thanks!

I’ve been messing around with OpenWrt for a while and wanted something that gave me a better view of everything without replacing the firmware or sending my network data through somebody else’s cloud. So I ended up building oonfeeWRT.

It runs on your own server, NAS, mini PC, or Mac and manages your existing OpenWrt devices from one place. The routers stay on normal OpenWrt, LuCI still works, and it doesn’t install custom firmware or randomly change configuration behind your back.

It’s completely self-hosted. There’s no oonfeeWRT cloud service, required online account, analytics, usage tracking, or automatic crash reporting. The router telemetry used for the dashboard stays on your machine and nothing is automatically sent to me. The optional speed test contacts Cloudflare when you choose to run it, but otherwise the controller talks directly to your own devices.

And before anyone asks: yeah, some of this was vibe coded. I’ve used AI to help me move faster, but the project is also based on my own experience and extensive knowledge of routers, computers, networking, and cybersecurity. I’m using it as a project for my university classes too, so it’s been a good excuse to turn that knowledge into something people can actually use. The security boundaries, adoption process, rollback behavior, and privacy decisions weren’t just randomly generated and accepted.

You can see devices, clients, radios, Internet health, topology, logs, and RF information. It can also manage networks, VLANs, DHCP, firewall zones, and Wi-Fi. Changes are shown before they’re applied, and it uses OpenWrt’s rollback timer in case something goes wrong halfway through.

I’ve only tested it on a Linksys WRT3200ACM and TP-Link Archer C6 v2 so far, which obviously isn’t enough hardware. There’s still a few rough edges, and I’m sure people will find some strange device-specific behavior.

One thing I added that I think will help with that are downloadable diagnostic bundles. If something breaks or your router isn’t detected properly, you can generate one and send it to me with the issue. It leaves out passwords, Wi-Fi keys, private keys, sessions, and other sensitive data. The bundle is never uploaded automatically—you decide whether to generate it and who to send it to.

The first release is here:

https://github.com/aiden0rchad/oonfeeWRT

If anyone wants to try it, especially on hardware I don’t own, I’d genuinely like to hear what works and what doesn’t. Bug reports, complaints, compatibility results, and feature ideas are all useful.

I wrote uapi because I wanted to manage my own router with Terraform. Every other option had a problem. Some exposed the anonymous section indexes of uci, so Terraform lost track of a resource between two applies. Others ran a separate daemon that drifted when LuCI wrote to the configuration.

uapi runs as a uhttpd-mod-ucode handler. There is no extra daemon and no second copy of the state. It never writes to /etc/config/ directly, so uci stays the source of truth.

What it does:

• 48 endpoints across 44 resource modules. For a package without a module, /raw/<package>/<id> gives direct access.
• One HTTP write is one transaction. uapi takes a snapshot, validates the body, commits it, then reloads the service. If the reload fails, uapi restores the snapshot.
• POST /batch puts changes to several packages into a single transaction.
• Bearer tokens carry scopes, an optional expiry date, an optional source IP range, and a rate limit.
• The router serves its own OpenAPI 3.1 specification at /api/v3/openapi.json.
• A read reports what uci holds and what the daemon does. If the two disagree, the response says so. uapi never repairs the difference on its own.

The provider is the reason uapi exists, and it is the client I use every day. It covers 40 resources and 43 data sources, which is most of the API.

Both registries carry it under the same name, openwrt-iac/uapi. It needs Terraform 1.0 or later, or OpenTofu 1.11 or later. The ephemeral resource uapi_token needs Terraform 1.10 or later. The current version is 3.0.1.

terraform {
  required_providers {
    uapi = {
      source  = "openwrt-iac/uapi"
      version = "~> 3.0"
    }
  }

To install it on your router:

Requirements: OpenWrt 25.12 or later, because the package uses apk. The package is architecture independent. All dependencies come from the base feed.

uclient-fetch -qO /etc/apk/keys/uapi-feed.pub.pem \
    https://openwrt-iac.github.io/feed/uapi-feed.pub.pem
echo 'https://openwrt-iac.github.io/feed/packages/all/uapi/packages.adb' \
    > /etc/apk/repositories.d/uapi.list
apk update && apk add uapi

A LuCI app for token management is in the same feed (luci-app-uapi).

Source and documentation: https://github.com/openwrt-iac/uapi

This is version 3.0.0, and it is not a first release. The first version came in May, and 20 releases came after it. I ran each one in production on my own network. I made many changes in that time. I post it here now because I am satisfied enough to ask other people to look at it.

That is also what I want from this post. Tell me what is wrong with it, and be direct about it. If you think a design decision is wrong, I prefer to hear it now, before other people depend on it. If you find a place where uapi rejects a configuration that OpenWrt itself ships, that is the error class I care about most. Open an issue, or answer here.

Thanks for your attention.

I am thinking of replacing my existing home wifi router with a Banana Pi BPi R4 running OpenWRT.

I want to do this as it enables me to do a lot of fun networking homelab related projects, including setting up WireGuard, network level adblocking, maybe some NAS stuff with the NVMe baked in if memory prices ever drop, and even replace my fiber modem with the Pi itself

I work from home, and am in lots of video meetings, so I need my WiFi to be reliable.

I've seen a few threads stating that the Wi-Fi card can sometimes show as online but not transmit, that the TX power can be low, that MLO can be unstable, and the 320hz band can be inconsistent.

Are these real issues people are experiencing or edge cases with low incidence?

Is it stable enough for a home router?

I am new to openwrt,I have an OPPO 5G CPE T1a (CTC03) running firmware CTC03_11.B.028_109.

I'm wondering if anyone has successfully installed OpenWrt (or another custom firmware) on this device, or found a way to unlock/modify the stock firmware to get more router functionality.

I'm particularly interested in this because the stock firmware doesn't seem to have a proper AP mode. I'd like to use the T1a as a proper wired AP/router instead of relying on the same-SSID/password workaround.

The device has:

• 5G cellular modem
• Wi-Fi 6
• Gigabit Ethernet
• Firmware: CTC03_11.B.028_109
• Model: OPPO 5G CPE T1a / CTC03

I'm interested in any information about:

• Existing OpenWrt support
• Whether the bootloader can be unlocked
• Serial/UART access
• Recovery mode or firmware flashing
• Hardware revisions that are/aren't supported
• Any known custom firmware projects
• Whether the Qualcomm platform is supported by OpenWrt
• Even just a way to configure the stock firmware as a proper wired AP

I haven't tried flashing anything yet, so I'm looking for information before potentially bricking the device.

If anyone has worked with this exact model/firmware, I'd really appreciate any pointers.