Flashing OpenWrt on a Netgear R6220 — via Telnet, When the Web UI Says No

Objective

Replace the Netgear R6220’s stock firmware with OpenWrt to get a fully controllable Linux router — proper firewall rules, packet capture, syslog export to the SIEM, and a package ecosystem — and document the recovery-style flash path required when the vendor’s web UI refuses third-party images.

Tools & Technologies

Netgear R6220 — MediaTek MT7621 (MIPS), the lab’s LAN gateway
OpenWrt 25.12.4 — squashfs kernel + rootfs factory images
Telnet console (vendor debug interface) and mtd_write for raw flash writes

Architecture / Workflow

Stock firmware
  └─ enable hidden Telnet console
       └─ transfer OpenWrt squashfs images to the router (USB)
            └─ mtd_write kernel image  → Kernel partition
            └─ mtd_write rootfs image  → Rootfs partition
                 └─ reboot → OpenWrt 25.12

What I Configured

1. Why the normal path failed. Newer Netgear firmware validates uploaded images and rejects OpenWrt outright in the web UI — the documented workaround is the vendor’s hidden Telnet console.

2. Unlocking Telnet. Netgear ships a debug backdoor: sending the right unlock request enables a root Telnet console on the stock firmware — no exploit, just an undocumented vendor facility.

3. Staging the images. I copied the OpenWrt squashfs kernel and rootfs factory images onto a USB drive mounted by the stock firmware, giving the Telnet session direct access to both files.

4. Writing flash directly. With the MTD partition layout identified, mtd_write wrote each image to its partition — kernel image to the Kernel partition, rootfs image to the Rootfs partition. This is the step with no undo: a wrong partition target bricks the device, so I verified the partition map twice before writing.

5. First boot into OpenWrt. After reboot the router came up on 192.168.1.1 running OpenWrt. From there: package installs via APK (OpenWrt’s newer releases replaced opkg), syslog-ng for log export to Splunk, tcpdump for packet capture, and Wi-Fi configured across both radios (2.4GHz + 5GHz).

Add terminal screenshots or serial output captures from a future reflash/upgrade — the original flash session wasn't captured.

Key Findings

Vendor lockouts usually have a maintenance path underneath — the same Telnet facility Netgear uses for debugging is the community’s supported install route.
On MTD-partitioned devices, understanding the flash layout is the safety procedure. The difference between a working router and a brick is one partition name.
The uplink design is unconventional and works: a TP-Link RE750C extender bridges the home Wi-Fi wirelessly and hands ethernet to the R6220’s WAN port — the lab router gets a real WAN interface (10.0.0.231/24) without touching the landlord’s network.

Skills Demonstrated

Embedded Linux and firmware internals, MTD flash partitioning, recovery-mode device administration, risk assessment on irreversible operations, router/network administration on OpenWrt.

What I Learned

Reading the hardware-specific documentation completely before touching flash is the whole game. Every brick story in the forums traces back to skipping the partition-layout paragraph. I treated the flash like a production change: verified prerequisites, confirmed the rollback story (TFTP recovery exists for this device), then executed.

Next Steps

Enable softflowd on OpenWrt to export NetFlow into the SIEM pipeline
Segment the lab onto VLANs with firewall zones between lab and personal devices
Document a TFTP de-brick/recovery drill so the failure path is tested, not theoretical