From E-Waste
to SpookyWrt

A router that fought back

The Seeed LinkStar H68K is a fanless Rockchip RK3568 mini-router: quad-core Cortex-A55, 2× 2.5 GbE + 2× 1 GbE, an optional Wi-Fi 6 radio, ~32 GB eMMC — a genuinely capable little box for $99. It ships with a vendor Ubuntu 20.04 / Android 11 image.

And that image is where it all goes wrong. The hardware is fine. The software it shipped with is the junk. Here's what we found on a fresh unit:

• adbd on 0.0.0.0:5555
  Android Debug Bridge listening, unauthenticated, on the LAN — a root shell to anyone on the network. On a router.
• Wi-Fi simply doesn't work
  The MediaTek MT7921 radio has no driver on the vendor's 2019-era 4.19 kernel. There is no wlan interface. At all.
• The 2.5 GbE ports are flaky
  Same story — the RTL8125B driver on the vendor kernel doesn't reliably bring them up.
• cleartext FTP · no firewall · shared SSH host keys
  vsftpd on :21, iptables wide open, and SSH host keys baked into the image — every unit worldwide shares the same keys (trivial MITM).
• Default passwords, no security updates
  root/root, linkstar/linkstar, on an OS that stopped getting patches. This is the "don't trust hardware from China" story in one image.
• No RTC → the clock is wrong on every boot
  No battery-backed clock, so it boots to a 2022 date and apt refuses every repo ("Release file is not valid yet"). TLS breaks. Nothing updates.

The verdict: a fast, cheap, 4-port router with a modern SoC — running an abandoned, insecure OS on a kernel too old to drive its own radios. Half-asleep and wide open. So we replaced all of it.

Three evolutions

Root-cause analyses

What was broken — and how we fixed it

This is the engineering meat — five non-obvious problems, each diagnosed to the actual cause, not the symptom.

• Wi-Fi didn't workThe router's brain (its software "kernel") was too old to know how to use its own Wi-Fi chip. We gave it a modern brain — Wi-Fi came to life.
• It wouldn't accept a fresh installThe factory image was packaged in an odd format that a normal copy can't boot. We figured out the format and wrote a tool that flashes it correctly.
• Faster (6 GHz) Wi-Fi stayed darkTwo things: a missing driver file, and a regional radio rule that blocks it. We added the file and set the right region — 6 GHz works.
• VPN wouldn't connectOne line of settings was in the wrong place, so it silently failed. We fixed the format and made it a one-command setup.
• It looked finished but wasn't safeAutomated checks all passed — yet a security review found serious holes hiding underneath. We fixed every one before shipping.

Two AI agents built this

The entire thing — the RKFW reverse-engineering, the 25 docs, the four web UIs, the security remediation, the on-device tooling — was built by two Claude agents working in parallel, coordinating like a small engineering team.

How they stayed out of each other's way

One rule made parallel work collision-free: partition by file, coordinate at the seam. A shared COORDINATION.md + staging directory was the message bus. The device agent never touched the repo; the repo agent never touched the box. When one edited the other's file, it left a note. Bugs hid at the boundaries — and got caught there (the device agent flashed an image the repo agent had marked "done" and found it wouldn't boot).

They spawned sub-agents, too

For hard problems, each agent fanned out specialists: a 3-agent adversarial audit (security / correctness / UX, each with a different hostile lens), research agents to source the wireless chipset matrix, and a verification swarm that build-tested the Wi-Fi-audit package manifest against the live OpenWrt build server before a single package was committed.

Why diverse agents beat one: the security auditor assumes the user is malicious; the code reviewer assumes the author erred; the UX auditor assumes the user is confused. A single reviewer averages those lenses and misses the sharp cases each catches. The audit found the cosmetic consent gate, the ASU-rejecting build command, and the shipped weak password — three different failure modes, three different reviewers.

What ~22 hours produced

Tokens consumed: [ FILL FROM DASHBOARD ] · Model: Claude (Opus/Sonnet) · Every push gated on shellcheck, markdownlint, link-check, and Python compile — no "trust me," evidence before assertions.

The deliverable is a complete firmware program, not a proof of concept: a no-maskrom flashing toolchain, four build variants (flagship / Wi-Fi-audit / VPN / AI), an on-device control shell, a ubus-powered web dashboard, a branded LuCI theme, a router-native LLM agent, and 25 docs — every hard-won gotcha turned into a guardrail so the next person doesn't rediscover it at 2 a.m.

A router with a face

Not a config file and a prayer — a real control surface. A ubus-powered dashboard, a build-your-image configurator, an on-device control shell, and a branded LuCI theme. All the hardware, finally usable.

Roadmap

SpookyWrt already runs great on the H68K. Next up: making it run on more popular little computers, and offering ready-made "editions" for different kinds of users.

The toolkit is OpenWrt-target-agnostic by design — the flashing pipeline and the whole SpookyWrt userland port to any board OpenWrt supports. Priorities:

Build log

This teardown is a living document — updated as we build. Newest first.

It's all open

MIT-licensed, CI-green, and live. Flash your own H68K — or any OpenWrt box — and never buy a router's software story on faith again.