Cudy WR3000P v1
The Cudy WR3000P is a Wi-Fi 6 (AX3000) router built around the MediaTek MT7981 (Filogic 820, 64-bit dual-core Cortex-A53, 1.3 GHz per Cudy's spec), with 1×2.5 Gb WAN (PoE-in) + 4×1 Gb LAN, a USB 2.0 port, and 4 non-detachable antennas. It is closely related to the Cudy WR3000H: the main differences are the WR3000P's 512 MB RAM (2× the H), a USB 2.0 port, and 802.3af/at PoE-in on the 2.5 Gb WAN port.
Supported Versions
Flash-chip change under the same “v1” — read before flashing. Cudy shipped an undisclosed SPI-NAND change without bumping the version: newer units use a newer ESMT F50L1G41-family flash that older OpenWrt or older Cudy intermediate images cannot boot. The generation is not reliably identifiable from the serial number, so the safe rule is simply: use OpenWrt 24.10.5 or newer — the release that added support for the newer flash — and a current Cudy intermediate image. Older images may not boot. If unsure, confirm the actual chip on-device first (dmesg reports the ESMT part family).
Installation
Back up the per-unit Factory and bdinfo partitions. Factory holds this board's Wi-Fi radio calibration and bdinfo holds its MAC addresses — both are unique to the unit and in no download, so if the NAND is ever wiped they are gone for good. The normal install route below preserves them (sysupgrade only rewrites the ubi partition), so you don't have to capture them before flashing — do it once you have a shell, most easily from OpenWrt after the sysupgrade:
dd if=/dev/mtd2 of=/tmp/Factory.bin # radio calibration dd if=/dev/mtd3 of=/tmp/bdinfo.bin # board data / MACs
then copy both off the device (scp). Do capture them *before* any ubootmod conversion or other low-level re-partitioning — that is the operation that can overwrite them. (Recording the MACs from the label is a cheap extra safety net.)
Via OEM web UI (no soldering)
Why two flashes? Cudy's stock firmware only accepts firmware images that Cudy has cryptographically signed, so official OpenWrt cannot be flashed onto it directly. Cudy's workaround is a signed “intermediate” image — an OpenWrt build that Cudy has signed — which the stock firmware *does* accept. Flashing it first lands you on a plain OpenWrt/LuCI system that enforces no such signing check; from there you flash the official OpenWrt sysupgrade image normally. So the intermediate is a one-time stepping-stone to get past the signed-firmware lock, after which you are on mainline OpenWrt.
- Download the Cudy-signed OpenWrt intermediate image. It is on Cudy's OpenWrt Software Download page (which also carries the flash-generation warning); that page's “Drive” link opens Cudy's shared Google Drive folder → take
WR3000P 1.0.zip(use the current, post-November-2025 build to match the newer flash — see the warning above). The stock firmware is on the model's download-center page. - Download the official OpenWrt
…cudy_wr3000p-v1-squashfs-sysupgrade.bin. - Power on and complete basic setup at http://192.168.10.1.
- Flash the Cudy-signed OpenWrt (intermediate) image via the OEM firmware-upgrade page; wait for the reboot.
- The intermediate is an OpenWrt build, so it comes up on the usual OpenWrt LAN (typically http://192.168.1.1). Open LuCI there → System → Backup / Flash Firmware and flash the sysupgrade image. Uncheck “Keep settings” (standard when moving across major versions).
Via serial / TFTP
This section is a stub — contributions welcome. A serial + TFTP install is possible; the initial support commit (PR #19636) is the reference (UART 115200 8N1, 3.3 V; U-Boot tftpboot an initramfs image, then sysupgrade). The exact solder-pad locations / pinout and a tested step-by-step have not been documented here yet — if you have done this on a WR3000P, please fill in the details.
Flash Layout
dev: size erasesize name mtd0: 00100000 00020000 "BL2" mtd1: 00080000 00020000 "u-boot-env" mtd2: 00200000 00020000 "Factory" mtd3: 00040000 00020000 "bdinfo" mtd4: 00200000 00020000 "FIP" mtd5: 04000000 00020000 "ubi"
The OEM layout leaves ~44 MB usable for OpenWrt's overlay. An optional U-Boot layout (ubootmod) was added in the OpenWrt 25.12 series (PR #22625, for WR3000P/H/S/E): it replaces the BL2 + FIP bootloader with mainline U-Boot — the ubi partition grows to ~122 MB (per PR #22625; ~95 MB usable overlay after kernel/rootfs is a derived estimate, not measured on our units) — plus a U-Boot TFTP/web recovery, at the cost of a bootloader replacement (a bad BL2 needs serial/hardware recovery).
LEDs
The front panel has 10 indicators, driven three different ways:
| LED | Driven by |
|---|---|
| System, Internet, 2.4G, 5G, USB | SoC GPIO (pio 11 / 6 / 7 / 9 / 4) — standard netdev / mac80211 (phyN…) triggers |
| LAN1–LAN4 | MT7531 switch hardware |
| WAN | Realtek RTL8221B PHY LED1 (not a SoC GPIO) |
WAN LED
The WAN LED does not light on a fresh OpenWrt install. The DTS led-wan node (GPIO pio 5, inherited from the 1 Gb WR3000) drives nothing on this board; the WAN lamp is wired to LED1 of the Realtek RTL8221B-VB-CG (C45) WAN PHY, whose power-on default lights only at a 1 Gb link — so on the 2.5 Gb WAN it stays dark. No kernel before Linux 7.2 has rtl822x PHY-LED support (added in 7.2, commit ''d3aae4d954f9''), so this cannot be fixed via the DTS on current OpenWrt.
To drive it from userspace (needs mdio-tools + kmod-mdio-netlink), on every WAN ifup. These register writes are specific to the RTL8221B — confirm your WAN PHY first with dmesg | grep -i phy.
mdio mdio-bus 6:0x1f 0xd032 0x0000 mdio mdio-bus 6:0x1f 0xd036 0x0000 mdio mdio-bus 6:0x1f 0xd040 0x391f # activity: 0x391f = blink on traffic, 0x391d = solid mdio mdio-bus 6:0x1f 0xd034 0x00a7 # link speeds lit: bit0=10 bit1=100 bit2=1000 bit5=2500
0xd034 = 0x00a7 lights the WAN LED at every link speed; 0xd040 bit 1 selects blink-on-traffic (0x391f) vs solid (0x391d). The register meanings were cross-checked against the mainline realtek PHY driver; see PR #19636 (the port PR that first noted “WAN LED does not light up”).
2.4G / 5G LEDs
Real GPIO LEDs (pio 7 / 9). They are dark on a fresh install only because OpenWrt ships the radios disabled and the DTS uses phyNtpt (activity) triggers — enable a radio, or use a default-on / phyNradio trigger, and they light.
Recovery / Debricking
Soft-brick: Cudy publishes a generic TFTP recovery guide — serve the WR3000P OEM image. Hard-brick / rollback to OEM: the OEM TFTP install path from the support commit (U-Boot shell, tftpboot), which requires the partition backups taken before flashing. (Not tested by this page's author.)
Notes
- PoE-in (802.3af/at, 48–57 V, 18 W) on the WAN port — powered-device only. Untested under OpenWrt at time of writing.
- USB port speed — controller vs. port. Cudy specs the port as USB 2.0, and that is its usable speed. Worth knowing: the MT7981's on-chip xHCI controller *does* report USB 3.x capability in
dmesg(xhci-mtk … Host supports USB 3.2 Enhanced SuperSpeed) — but that is the SoC controller, not the port wiring, so don't infer a 3.x port from that line. - The _EU / _US suffix is a retail SKU / packaging distinction, not an OpenWrt one — the same profile (
cudy_wr3000p-v1) and the same Cudy image apply. Set your Wi-Fi country in OpenWrt config yourself. (We have only _EU units on hand; the _US equivalence is inferred from the single OpenWrt profile and the Cudy image metadata, and the OEM Wi-Fi regulatory-domain default was not checked.)
Photos
Labels / addressing format
Read off the underside label (per-unit values are redacted in the photo above; the formats are what's documented here):
- Management: http://192.168.10.1 (or http://cudy.net). Power: 12 V / 1.5 A, or PoE-in 802.3af/at 48–57 V, 18 W.
- Default Wi-Fi SSID:
Cudy-XXXX/Cudy-XXXX-5G, whereXXXXis the last four hex digits of the MAC (e.g. a unit whose MAC ends…F9:52broadcastsCudy-F952). - MAC: OUI D4:0D:AB (Cudy). The label MAC is the LAN/base address; the WAN MAC = base + 1 (e.g.
…F9:52→ WAN…F9:53). - Serial number: appears to encode a date — our units read
S00071812611…, which we read as a YYWW2611= 2026 week 11 (field boundaries inferred from two same-week units, not from a Cudy spec). - Default Wi-Fi password: an 8-digit numeric key printed on the label — per-unit, not a universal default (redacted here; and note the OEM label credentials are irrelevant once the device runs OpenWrt).





