Flashing Cudy AP3000 Outdoor V1

I'm new to OpenWrt so I could be doing 100 things wrong, but this seems like it should be straightforward. I'm trying to install it on a Cudy AP3000 Outdoor (V1 = only HW version so far I think). No matter what I do, it's non-responsive (Ethernet or WiFi) and the LED is red, or sometimes flashing red/green.

I've done this many times with no luck. First step: upload the intermediate image from Cudy's web site. That yields this:

So far so good (trying to upload openwrt-24.10.0-mediatek-filogic-cudy_ap3000outdoor-v1-squashfs-sysupgrade.bin at this prompt gives an error, because of its being unsigned I assume, so I assume what I'm doing here is installing a Cudy image that's willing to flash alien unsigned images). When I click Proceed, it counts happily away by 5s, but the LED on the unit stops flashing somewhere in there (well before 100%) and switches to solid red, and when I reboot, there's no one home.

Reflashing the stock firmware from Cudy's web site using TFTP to 192.168.1.88 works fine and gets me back to a stock setup (booting with the button held but no TFTP server lets me set an admin password and go from there), but I still can't flash the intermediate image, or the OpenWrt image either obviously. Renaming either of those to "recovery.bin" and trying to do it directly via TFTP doesn't work either, but just because everything ends in ".bin" doesn't feel to me like proof that it's all in the same format. Plus there may still be signing checks. So I'm not surprised by that but maybe I would be if I knew more.

Looking through the forum for other AP3000 Outdoor users, it looks like what I did works for some people but not for others. How can I become "some people"? I'm no stranger to technical stuff but this is my first time on OpenWrt so I have no idea of the culture or expectations. So for example I'm sure I could rig up a serial connection inside but I wouldn't know what to type.

Tnx / John

Install the kernel (initramfs) version first from the stock firmware. Then apply the sysupgrade image once you are booted into openwrt - this will make it persistent.

Hmm stuck already. I don't see any downloads for my device that mention initramfs. What is squashfs? That's the one it refuses to even try to flash. Thanks for replying!

Grab the kernel for the initial install. Sysupgrade after that.

How is that firmware menu totally different from the one I had found? I'm getting old. Well OK I grabbed that but it won't install either:

I tried flashing both older and newer stock Cudy firmware just to maximize the number of variables. That always makes this stuff easier, right? Neither one seems to want to install anything other than stock Cudy firmware.

Ah... you might need the intermediate firmware linked here:

Yep, that file diffs as identical to the one that won't load in my first screen grab. This is where I'm stuck -- that image doesn't really work, installed from Cudy's current or original firmware, and I don't know why not. Or it DOES work and I'm too stupid to get the device to talk to me after it's been flashed. Or somehow both.

I don't own this device, so the best I can do in this case is point you to the resources I was able to locate.... hopefully someone else knows how to get OpenWrt on your unit.

The Cudy interim images are usually flawless...

You could try to feed it the Openwrt 24.10 image through TFTP instead - https://www.cudy.com/blogs/faq/how-to-recovery-the-cudy-router-from-openwrt-firmware-to-cudy-official-firmware.

Well I appreciate the help! Obviously operator error is always a possibility so this information might all be 100% correct. It's really not feeling that way though.

Apparently no good. I'd already tried the squashfs one and I just did the initramfs one too and still the only thing that works via TFTP for me is Cudy's own images. Those finish loading and then the LED switches to long green blinks. With the OpenWrt ones it never gets there (loops forever on bright/regular green or some other thing and then blinks fast red/green if I power-cycle it). Really feels like all this stuff was supposed to work so I'm really wondering if we're all agreeing on what a .bin file looks like.

you wrote the above in your 1st post ... how was this verified ?
the Cudy interim image from GDrive might not have Luci, and you need to use ssh to flash openwrt ...

Here's where my lack of experience is most likely to be biting me. My laptop shows no SSID for it, and my main Asus router's DHCP client list doesn't show the unit (with an 80:AF:CA MAC prefix). So I wouldn't know what IP address to SSH to. Ping to 192.168.1.168 (which was its address a minute ago under Cudy's firmware) gets no reply. So I think it's bricked. Easily restored to Cudy's firmware with TFTP each time though.

router IP would most likely be 192.168.1.1, even when using the interim image.

isolate the AP and your client, connect to it using an Ethernet cable, wifi is off.

if your client receive an IP in the 192.168.1.X subnet, you're good.

Further evidence: when I upload cudy_ap3000outdoor-v1-sysupgrade.bin (the intermediate image) to the unit using Cudy's firmware to upload it, it apparently likes the signature/header/checksum/whatever and prompts me to proceed as I showed above. Then it does the "flashing" sequence, during which the unit's LED does slow red/green blinks. But then around 20% it switches to fast red/green blinks, and by 30% it's solid red which never goes off. Rebooting gives solid red.

Meanwhile if I use Cudy's firmware to flash Cudy's firmware (same version), it does the slow red/green blinks until around 20%, then, flashing green until 50%ish, then solid green, and everything's fine.

So clearly the unit gets upset while it's still flashing the intermediate firmware, which I would think is before it's executed a single byte of the new code. To me that says the .bin file has some sort of internal structure (records vs. a raw flat image) which is corrupted. Otherwise why would the flash routine notice and change the LED behavior? I re-downloaded/re-unzipped it from Cudy's Google Drive with no change.

worst case scenario, you could ask Cudy, they're surprisingly good at answering :slight_smile:

https://drive.google.com/drive/folders/1BKVarlwlNxf7uJUtRhuMGUqeCa5KpMnj is where I'm getting the image. It was linked to by Cudy, but maybe it's not real? My main Asus router is already 192.168.1.1 and I'm confused about hooking to the AP3000's Ethernet port. I would assume it sees itself as a client on that network, at least until we've done the setup and found out if it's filling some other role. Being a DHCP server on someone else's LAN right off the bat seems un-neighborly!

looks like the same one Cudy's posted at https://www.cudy.com/blogs/faq/openwrt-software-download.

that's why you were told to isolate it and the client.

it doesn't.

it'll just sit there and be quiet, but the IP will still overlap.

1 Like

I guess I may be at the point of contacting them! This seems like it should have been straightforward. I'd suspect the unit itself, except that it's perfectly happy flashing three different versions of Cudy's own stock firmware.

DUDE! I am at a shell prompt! This is fantastic -- thank you! I'm pretty hazy on what to do next but I'll bet it'll be obvious after I do it. It is not a brick. Thanks!!!!!!

1 Like