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.

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).

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.)

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.

  1. 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.
  2. Download the official OpenWrt …cudy_wr3000p-v1-squashfs-sysupgrade.bin.
  3. Power on and complete basic setup at http://192.168.10.1.
  4. Flash the Cudy-signed OpenWrt (intermediate) image via the OEM firmware-upgrade page; wait for the reboot.
  5. 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).

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.

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).

Top surface — the 10 LED legends

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)

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”).

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.

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.)

  • 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.)

Overall (rear three-quarter) Rear port panel Underside label — MAC, serial and default Wi-Fi key redacted Top-down (background removed)

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, where XXXX is the last four hex digits of the MAC (e.g. a unit whose MAC ends …F9:52 broadcasts Cudy-F952).
  • MAC: OUI D4:0D:AB (Cudy). The label MAC is the LAN/base address; the WAN MAC = base + 1 (e.g. …F9:52WAN …F9:53).
  • Serial number: appears to encode a date — our units read S00071812611…, which we read as a YYWW 2611 = 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).
  • Last modified: 2026/08/25 16:29
  • by ivanthegeek