The Cudy AX3000 Wi-Fi 6 System (With OpenWRT)

Sep 14^th 2025 · 12 min read · #ax3000 #cudy #hardware #homelab #m3000 #networking #openwrt #reviews #wifi

As I’ve been writing about once or twice, I’ve recently upgraded my Wi-Fi after an attempt to use ISP-provided equipment to replace my remarkably long-lasting (and extremely reliable) Airport Extreme base stations.

The short of it is that I ended up getting a few Cudy M3000 and setting up OpenWRT on them:

The M3000 standalone router/access point

Disclaimer: Although I sought out (and paid for) several M3000 units myself, I’m following my standard format and review policy for consistency, since this is more or less a “review”.

The long of it has been a somewhat fun journey, so here’s the full story.

In case you’ve landed here without any context, I recently switched ISPs and the initial configuration included a set of Wi-Fi 7 extenders to replace my (very) long-lived Airport Extreme base stations.

This was a somewhat protracted thing and I had plenty of time to lay down the groundwork by upgrading my LAN to 2.5GbE Ethernet with a few 10GbE ports, but after a week of living with the system I decided I wanted something I could manage myself due to a bunch of management restrictions and outright compatibility problems I could not re-configure it to overcome, because everything is locked out by my ISP.

My functional requirements were pretty clear:

• Fully local, browser-based management (I don’t mind managing each device individually).
• Absolutely zero cloud management features. Zilch. Nada. No setting up a user account with the vendor or any external dependencies (I don’t want or need off-site remote management—and if I did, I could set it up myself.)
• No mobile apps required (or desirable) for either initial setup or daily tweaks (which was something I actually didn’t like about the Airport Extremes even if it was very convenient to have management baked into iOS).
• Not an ugly arachnoid eyesore (we can’t hang access points off walls or ceilings, and the Airport Extremes became effectively invisible in plain sight).

And the M3000 doesn’t look half bad compared to an Airport Extreme, so that was definitely a reason for me to take a second look (they come in black too, but the white ones were drop-in replacements for the Airports in our decor).

As you can see, they are pretty neutral. I will miss the extra LAN and USB ports, though.

Technically, I had a few more requirements:

• I wanted “dumb” access points. No routing, no meshing, no weird/proprietary vendor features—just a box able to turn Ethernet packets into radio and back again.
• I decided to aim for Wi-Fi 6/6E (I quickly realized that we only have a couple of MacBooks able to do Wi-Fi 7 and that most of our devices are Wi-Fi 6 capable).
• Full control over all Wi-Fi features (channel, SSIDs, power, etc.) with support for an arbitrary number of SSIDs (with VLAN mapping of each) on both 2.4/5 GHz (or 6 GHz if available).
• No band steering (it does not really work in our scenario, and one of the biggest gripes I had with our ISP setup was that I couldn’t turn it off).
• 2.5GbE backhaul (gigabit-plus Wi-Fi is useless if you can’t pipe it through.)
• At least one pass-through Ethernet port (the Airport Extreme has three additional GbE ports, which is still apparently a premium configuration over a decade later but has proven very, very handy)

OpenWRT was not really a requirement, but since my first-ever Wi-Fi access points were indeed WRT54G devices and I have a long history with it, that’s where I started my research, and Cudy hardware had quite a few positive references.

Moreover, they actually provide instructions on how to re-flash their devices with OpenWRT, and there is an upgrade path to the currently supported version (as well as a likely runway of official OpenWRT support for a few years at least), so they soon rose to the top of my list.

The factory firmware is actually very nice, and makes an excellent job of exposing all of the features as well as guiding users through initial setup of the devices either as a router or as an access point in various configurations:

The base Cudy UI is very comprehensive.

I didn’t run it for long, but it seems to do a very good job of exposing both OpenWRT core functionality and the additional features Cudy added. Although I didn’t install their app or tried to manage it remotely, I’d say most people would be well served by the factory firmware.

But my objective was to make sure I had full control of the hardware and run these on the latest vanilla OpenWRT, so there were a few more steps involved.

The first thing I needed to do was unlock the factory firmware. The white/grey devices I have are “V2” hardware, but Cudy themselves say that the firmware is identical to the V1 (which is black with red trimming) and provide a vanilla OpenWRT 23.05 image, so I started out with that.

The Cudy support page links to their Google Drive, where you can download the M3000 V1.zip file (for both V1/V2).

That ZIP file contains a Windows version of tftpd (which is an extra nice touch, even if it triggers a bunch of virus warnings), a comprehensive set of instructions for Windows users in a PDF and a few firmware files, which we’ll get to in a moment.

To get the latest supported firmware, I went to the OpenWRT Firmware Selector and looked for the Cudy M3000, downloading the latest sysupgrade file. I downloaded 24.10.2 (r28739-d9340319c6).

I then set up tftpd on one of my Fedora laptops (because, I don’t have personal Windows machines anymore) and wired it up to the LAN port on the M3000.

To enable it to get at the recovery.bin file via TFTP, I copied that file to /var/lib/tftpboot, set my laptop to IP address 192.168.1.88 and restarted tftpd.

I then held down the power button on the M3000, plugged in the barrel jack, waited until the lights settled (solid red in my case) and then reset my laptop to use DHCP, because the next step is to log in to the (now unlocked) Cudy web UI at http://192.168.10.1.

Once you’re there, go to Advanced Settings/Firmware and upload cudy_m3000-v1-sysupgrade.bin (checksum d09cdb39e9544b1d33a4daf28964c50b), which is also provided in the ZIP file.

This gives you a vanilla OpenWRT 23.05 install, and you then go to http://192.168.1.1/cgi-bin/luci/admin/system/flash, upload the 24.10.2 file and… you’re done.

• Connect to the LAN port.
• Set your IP address to 192.168.1.88.
• Start tftpd with the recovery.bin file in /var/lib/tftpboot.
• Plug in the power jack while holding the power button, wait until the lights settle (solid red in my case).
• Reconfigure your machine from 192.168.1.88 to DHCP.
• Log in to the Cudy web UI (http://192.168.10.1), go to Advanced Settings/Firmware and upload cudy_m3000-v1-sysupgrade.bin (d09cdb39e9544b1d33a4daf28964c50b).
• Wait for it to reboot.
• Go to http://192.168.1.1/cgi-bin/luci/admin/system/flash and upload the 24.10.2 sysupgrade image.

I initially got a standalone unit to test and then bought a 3-pack and another standalone unit (to keep as a cold spare), so I had a working configuration I could use to set up the new nodes way before I got them all.

Over that initial week with the first unit, I sorted out all of the details:

• Disabled the built-in DHCP server
• Added both Ethernet ports to the br-lan bridge to allow pass-through (this way I can plug an Apple TV or similar directly into the gigabit port)
• Set the timezone, checked that NTP worked correctly, etc.
• Installed rsync and luci-app-statistics to play around with configuration files and monitoring
• Set up the 2.4GHz radio for a “compatibility mode” that wouldn’t frustrate my IoT devices (including the many low bitrate ESP32s lying around)
• Set up WPA3 on the 5GHz radio to enable full 802.11ax data rates (I also punched up the channel width to 160Mhz and set up 802.11r for faster hand-overs)

This bit is probably the most interesting for everyone, so here’s a redacted version of my initial /etc/config/wireless:

To set up the other nodes, I just uploaded the first one’s configuration backup, changed the hostname and IP address (given the vagaries of our new home gateway, I opted for static IPs) and plugged them in.

My iPhone and MacBook Pro can both do 1.2 Gbps down / 1.5 Gbps up within 2–3 meters of any of the access points when connecting to our internal OpenSpeedTest instance—which I’m hosting on one of my TerraMaster’s 10GbE interfaces:

OpenSpeedTest hosted on my 10GbE NAS

Running a second simultaneous test gives obviously lower (but similar) individual results and maxes out the 2.5GbE uplink, so I would say this is about as good as it’s ever going to get, since I suspect that even if we were using Wi-Fi 7 and 6GHz, physics and the 2.5GbE backhaul would start factoring in.

Again, this is in a pure “flat” configuration, with all physical interfaces and radios set as part of the br-lan–no routing is taking place, and no layer 3 handling is happening.

Our staple latency test (streaming games using Steam Link from a 2.5GbE server) is buttery smooth, but then again it was already good with the Airport Extremes (you only really need 30-50Mbps for crisp 1080p streaming), and the Logitech G Cloud (which, ironically, has worse Wi-Fi than any of our iPads) works perfectly.

But I’ll let the data speak for itself:

PHY bitrate in my living room

This is the same kind of performance I was getting with the Wi-Fi 7 extenders from my ISP, but:

• I can now see it, monitor it and dive into the nitty-gritty details at will instead of having to guess what was happening.
• Even though it’s not Wi-Fi 6E, it is a massive improvement over the sub-300 Mbps I was getting from the Apple Airport Extremes.

So I’m calling this a success performance-wise.

There is some occasional flip-flopping between access points, but that only happens in Linux and in places where coverage has strong overlap, so I’m not worried about it (I can always turn off 802.11r if it becomes a nuisance, and I consider it an experiment, not a requirement):

This is a good example--I see a similar pattern in the nearest AP to this one

Looking at the logs from both APs involved it seems to be a client issue:

This hasn’t recurred, but I will be keeping an eye on things–and if you want to dig deeper into 802.11r configuration, this great page has a bunch of detail on it.

So far there haven’t been any unexpected behaviors, and since I am not using band steering (which you can add by installing usteer or dawn and their corresponding luci packages, by the way) everything’s been fine with my legacy devices.

While I was going through this process, I got a bunch of feedback from people online:

• Why not UniFi? Value for money, plain and simple. I have used Ubiquiti devices before, but I wasn’t going to pay three digits for a “dumb” access point and don’t need most of their features.
• Why not Wi-Fi 7? There isn’t anything similar with Wi-Fi 6E/7 support and 2.5GbE backhaul yet–at least not anywhere near this price point. Cudy does have other models, but they haven’t released unlocked OpenWRT firmware (yet, I hope) and besides, I am already getting gigabit-plus speeds for all my devices.
• What about meshing? It’s useless for me. We have reinforced concrete walls and two lift shafts in the middle of our flat and even 2.4 GHz has issues, which is partly why I made sure we have at least two Ethernet jacks in each room when we renovated over twenty years ago.
• What about roaming? This is a home (office), not an independent country. Standard Wi-Fi handovers work fine even if you walk around the house on a video call. I enabled 802.11r anyway but see no need for it.
• What about central management? It’s just four active devices, and they’re all set up as “dumb” access points, so there isn’t a lot to manage except when I’m setting up a new VLAN or need a test SSID. Gathering stats off luci-app-statistics via collectd is a wheel that’s already been invented, so I don’t need a controller for that.

All in all, I don’t even need the LuCI web UI, and if I need to test a complex configuration I can hack something together with ssh and ansible for reproducibility in around 30 minutes.

The Cudy AX3000/M3000 models make for pretty great Airport Extreme replacements, and in this age of networking devices with cloud features nobody asked for OpenWRT turns them into very nice locally managed access points that I will never have to worry about again (until I break the configuration myself, of course).

Although it is much too early to weigh in on hardware reliability (some of the 802.11ac Airport Extremes I was using were manufactured over a decade ago), the price/performance ratio is great, and right now I don’t mind it not being Wi-Fi 7.

After all, it took almost ten years for the 2.4GHz band to become saturated in my building, and it doesn’t look as if the 5GHz band is going to be massively swamped anytime soon, so I’m expecting something like 3-4 years of hassle-free operation if the hardware holds up.

A relevant thing I should point out again is that people who have less need for low-level control might actually be fine with the stock firmware—I did not use it extensively (nor did I try the Cudy app or any of the router/firewall features), but it already exposes a lot more functionality (and seems a lot more flexible) than ISP gear, so I would encourage people to give it a go.

I suspect I will eventually come across some OpenWRT corner cases as I succumb to the temptation to fiddle with the configuration a bit more, but given our particular situation there’s a very high chance these will just fade into the background and “just work”, which was the ideal outcome that Apple pretty much nailed with the Airport Extremes…