When “Pre-Installed OpenWrt” Isn’t Plug-and-Play

 

Lessons Learned After Finally Configuring a Raspberry Pi CM4 Mini Router (Bought in 2022)

Product

Mini Router built with Raspberry Pi Compute Module 4

• Dual Gigabit Ethernet NICs

• 4GB RAM / 32GB eMMC

• Pre-installed OpenWrt

• Compact form factor, fanless, low power

Background: A Device That Waited Its Turn

I bought this device back in 2022.

At the time, it looked like the perfect small router:

• Raspberry Pi Compute Module 4

• Dual Ethernet ports

• OpenWrt already installed

• No SD card required thanks to eMMC

But like many homelab projects, it ended up sitting on a shelf.

Fast forward to today — with more networking experience, a clearer home network plan, and a real need for a flexible router — I finally decided to configure it properly.

That’s when the real journey started.

What I Expected (Even in 2025)

Even knowing this wasn’t a consumer router, I still expected:

• Plug WAN into my upstream router

• Plug LAN into my laptop

• Access 192.168.1.1

• Have a working internet connection

After all, the product description still says “Pre-installed OpenWrt”.

In reality, “pre-installed” turned out to mean something very different.

The First Wall: Kernel Panic Before First Boot

Before even reaching OpenWrt configuration, the device would not boot properly.

What I encountered:

• Reboot loops

• Serial output showing kernel panic

• Inconsistent LED patterns

• No usable network access

• No clear indication whether it was booting from eMMC or external media

At this point:

• The router wasn’t misconfigured

• It wasn’t usable at all

Problem #1: “Pre-Installed OpenWrt” Was Broken

Despite being sold as pre-installed, the OpenWrt image on the eMMC was either:

• Corrupted

• Incompatible with the CM4 variant

• Or outdated beyond recovery

This is where the biggest problem appeared:

There is no single, authoritative guide explaining how to recover or reflash this device.

Problem #2: No Clear Documentation for eMMC Recovery

Most Raspberry Pi documentation assumes:

• A standard Raspberry Pi board

• Booting from microSD

• HDMI + keyboard access

None of that applied here.

This device:

• Uses CM4

• Boots primarily from eMMC

• Has no boot button

• Requires jumpers or pin grounding to force USB boot mode

Even identifying:

• Which pin disables eMMC

• When to apply power

• Which USB port acts as the device port

…required trial, error, and community posts. 

https://wiki.seeedstudio.com/OpenWrt-Getting-Started/#for-maclinux

The Breakthrough: Using rpiboot to Access the eMMC

Eventually, the only viable solution was to treat the device as a bare CM4 recovery scenario.

Using rpiboot:

• The CM4 eMMC was exposed over USB

• The storage appeared on the host machine

• The original OpenWrt image could finally be replaced

This step alone took multiple attempts, because:

• The board didn’t always enter USB boot mode

• LED signals were undocumented

• Kernel panic output was misleading

• Failure modes were silent

At this point, just seeing the eMMC show up felt like a victory.

---

Reflashing OpenWrt: Smaller Image, Big Confusion

After reflashing:

• The image was surprisingly small (~13–15 MB)

• This raised doubts about whether the flash had worked at all

But in reality:

• This is normal for OpenWrt factory images

• The root filesystem expands at first boot

This was another moment where documentation gaps caused unnecessary doubt.

---

Finally Booting… But Still Not a Router

After reflashing:

• The device booted

• OpenWrt was accessible

• LAN IP responded

• LuCI and SSH worked

But:

• No internet for LAN clients

• DNS resolution failed

• Connectivity was inconsistent

The hardest part?
Nothing looked broken.

Problem #3: OpenWrt Was Installed, Not Configured

At this stage, OpenWrt itself was fine — but the router wasn’t.

Key findings:

• WAN had connectivity

• Firewall zones existed

• NAT was enabled

• Forwarding was present

Yet LAN clients couldn’t browse the internet.

---

The Real Culprit: Missing DNS on LAN

The final issue was subtle but critical.

OpenWrt had working DNS:

8.8.8.8
1.1.1.1

But:

• LAN DHCP was not advertising a DNS server

• Clients had no idea where to resolve domains

This created the illusion of a broken network while routing was fine.

The fix:

uci add_list dhcp.lan.dhcp_option='6,192.168.10.1'
uci commit dhcp
/etc/init.d/dnsmasq restart

After renewing DHCP leases:

• DNS worked immediately

• Browsing stabilized

• The router finally behaved as expected

---

Why This Took So Long

Looking back, the struggle came from three separate layers of problems:

1. Broken pre-installed firmware

2. Undocumented eMMC recovery process

3. Incomplete OpenWrt default configuration

Each issue masked the next.

---

Final Working Architecture

• WAN (eth1)

  • DHCP from upstream router

• LAN (br-lan)

  • Static gateway

  • DHCP + DNS

• Firewall

  • LAN → WAN forwarding

  • NAT enabled

• DNS

  • Clients → OpenWrt

  • OpenWrt → upstream resolvers

This is now a proper OpenWrt router, ready for VLANs and homelab use.

---

Lessons Learned (The Hard Way)

• “Pre-installed” does not guarantee “bootable”

• CM4 devices require recovery knowledge

• eMMC adds power — and complexity

• DNS failures are the most deceptive network issue

• Lack of documentation is the real enemy

---

Final Verdict

This device is not bad hardware.

It is powerful, flexible, and capable — but only if you’re prepared to:

• Recover firmware

• Understand OpenWrt internals

• Debug at multiple layers

Buying it in 2022 and finishing the setup years later was painful — but educational.

This is not a consumer router.
It’s a network engineering project.

And once you accept that, it becomes a very good one.

---