Demystifying OpenWrt One: Building and Optimizing Custom Firmware for the First Official Open-Hardware Router

The Dawn of Open Hardware in Consumer Networking

The consumer router market has long been plagued by planned obsolescence, proprietary blobs, and abandoned security updates. While OpenWrt has served as the premier open-source firmware savior for third-party routers, developers have always had to reverse-engineer hardware or compromise on proprietary drivers. The announcement of the OpenWrt One—the project's first official, fully open-hardware router—marks a monumental paradigm shift.

Developed in collaboration with Banana Pi, the OpenWrt One is designed from the ground up to run open-source software, providing complete control over the network stack. This deep-dive tutorial explores the hardware architecture of the OpenWrt One and guides you through compiling, flashing, and optimizing a custom firmware image tailored for high-performance routing, SQM, and secure tunneling.

Under the Hood: The OpenWrt One Hardware Architecture

To build optimized software, we must first understand the silicon. The OpenWrt One is powered by the MediaTek MT7981B (Filogic 820) SoC, paired with the MT7531A switch. It is specifically designed to bypass the traditional pitfalls of consumer routers by implementing dual-boot recovery mechanisms and open schematics.

Silicon and Storage Topology

CPU: Dual-core ARM Cortex-A53 running at 1.3 GHz.
Memory: 1 GB DDR4 RAM (allowing ample headroom for running user-space applications, containers, and complex routing tables).
Storage: Dual-flash layout featuring 128 MB SPI NAND flash and 4 MB SPI NOR flash.
Networking: 1x 2.5 Gbps WAN port, 1x 1 Gbps LAN port.
Wireless: Wi-Fi 6 (802.11ax) dual-band MIMO.
Expansion: mikroBUS slot for hardware click boards (IoT sensors, LTE modems, etc.), and an M.2 M-key slot for NVMe SSDs or AI accelerators.

The dual-flash architecture is particularly ingenious. The 4 MB SPI NOR flash acts as a read-only, write-protected boot recovery medium containing the bootloader (U-Boot) and a recovery system, making the router virtually unbrickable. If a custom firmware compilation fails or corrupts the primary 128 MB NAND flash, the system automatically falls back to the safe NOR boot environment.

Step-by-Step: Compiling Custom OpenWrt One Firmware from Source

Compiling OpenWrt from source allows you to optimize the kernel compiler flags for the Cortex-A53 architecture, strip out unused legacy drivers, and bake-in critical packages like WireGuard and eBPF tools directly into the read-only squashfs system image.

1. Preparing the Build Environment

First, set up your build host. We recommend using an Ubuntu 22.04 LTS or Debian 12 environment with at least 4 CPU cores and 16 GB of RAM. Install the required build dependencies:

sudo apt update && sudo apt install -y build-essential libncurses5-dev gawk git subversion libssl-dev gettext unzip zlib1g-dev file python3 python3-distutils rsync wget

Next, clone the official OpenWrt source repository. To target the OpenWrt One, we will use the master branch or the specific release branch supporting the MediaTek Filogic target:

git clone https://github.com/openwrt/openwrt.git
cd openwrt

Update and install the package feeds:

./scripts/feeds update -a
./scripts/feeds install -a

2. Configuring the Buildroot Target

Launch the menu-driven configuration interface to define our architecture targets:

make menuconfig

In the configuration menu, select the following parameters:

Target System: MediaTek Ralink ARM
Subtarget: Filogic compatible devices
Target Profile: OpenWrt One (AP-MT7981)

This profile automatically configures the correct device tree bindings, partition layouts, and Wi-Fi calibration parameters for the MT7981B chip.

3. Customizing Package Selection (SQM, WireGuard, and eBPF)

Instead of installing packages post-flash via opkg (which writes to the writable overlay partition and consumes precious read/write cycles on your flash memory), we will bake them directly into the read-only rootfs.

Navigate through the menuconfig to enable the following:

Network -> Routing and Redirection -> ip-full (replaces ip-tiny for full routing capability)
Network -> VPN -> wireguard-tools and kmod-wireguard
Network -> Traffic Control -> sqm-scripts and luci-app-sqm (for Bufferbloat mitigation)
System -> htop and tcpdump (for diagnostics)

Once configured, save your configuration to .config and exit.

4. Compiling the Image

To accelerate compilation, determine the number of logical cores on your build machine and run the build process:

make -j$(nproc) V=s

The initial compilation can take anywhere from 30 minutes to 2 hours depending on your CPU. Upon completion, the compiled images will be located in the bin/targets/mediatek/filogic/ directory. The primary file for initial installation is typically named openwrt-mediatek-filogic-openwrt-one-squashfs-sysupgrade.bin.

Advanced Optimization: SQM Cake and Hardware Offloading

Once your custom image is flashed onto the OpenWrt One, you can leverage its dual-core Cortex-A53 CPU to implement advanced traffic shaping and offloading techniques.

Configuring Cake for Bufferbloat Mitigation

Bufferbloat occurs when network equipment buffers too many packets, causing high latency spikes during heavy bandwidth consumption. The OpenWrt One has more than enough computational power to handle gigabit-rate shaping using the modern CAKE (Common Applications Kept Enhanced) queuing discipline.

To configure SQM via the command-line interface (CLI), SSH into your router and edit /etc/config/sqm:

config queue 'wan'
    option enabled '1'
    option interface 'eth0'
    option download '950000'
    option upload '950000'
    option linklayer 'ethernet'
    option overhead '44'
    option qdisc 'cake'
    option script 'pieceofcake.qm'

This configuration limits the download and upload speeds slightly below your physical line rate (e.g., 950 Mbps for a 1 Gbps link) and applies the CAKE algorithm. CAKE automatically prioritizes latency-sensitive packets (like DNS queries, gaming inputs, and VoIP) over bulk data transfers (like OS updates or torrent downloads).

Enabling Packet Steering and Hardware Flow Offloading

While SQM is excellent for bufferbloat mitigation, it disables hardware offloading because packets must pass through the CPU's network stack for queuing. However, if you have a multi-gigabit connection (e.g., utilizing the 2.5 Gbps WAN port) and want to conserve CPU cycles, you can enable MediaTek's Hardware Flow Offloading (PPE - Packet Processing Engine).

To enable this, edit /etc/config/firewall:

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option flow_offloading '1'
    option flow_offloading_hw '1'

Enabling flow_offloading_hw instructs the MediaTek MT7981B SoC to route established TCP and UDP flows directly through the network switch silicon, bypassing the CPU entirely. This reduces CPU utilization to near zero even during 2 Gbps+ routing operations, leaving the dual-core processor free to run local DNS servers, VPN handshakes, and Docker containers.

Unleashing the Dual-Boot and Recovery Capabilities

One of the most powerful aspects of the OpenWrt One is its robust partition management. The internal storage layout contains separate partitions for secondary systems. You can leverage the U-Boot command line or the system's GPIO-controlled boot selection switch to test experimental kernels without risking a network outage.

If you are developing custom kernel modules, you can configure U-Boot to load images directly over TFTP from your development workstation:

setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.100
tftpboot 0x44000000 openwrt-mediatek-filogic-openwrt-one-initramfs-recovery.itb
bootm 0x44000000

This development loop allows you to rapidly prototype kernel-level network drivers, test eBPF programs, or experiment with custom routing protocols without repeatedly writing to the physical NAND flash.

Conclusion: A New Era of Network Sovereignty

The OpenWrt One represents a milestone for open-source enthusiasts, network engineers, and privacy advocates. By combining powerful, modern hardware with an open-source schematic design and a highly optimized, dual-boot recovery environment, it eliminates the artificial limitations imposed by commercial router vendors.

Whether you are deploying the OpenWrt One as a high-throughput edge router with aggressive SQM shaping, a secure WireGuard gateway, or an experimental IoT hub utilizing the mikroBUS expansion slot, building your own firmware gives you absolute sovereignty over your digital perimeter. The era of compromising on proprietary router platforms is officially over.