Add OpenWrt support for Ubiquity AirCube ISP (UBNT ACB-ISP)



I have a Ubiquity AirCube ISP. I think that this could be a nice device for OpenWrt. It has a good balance between price (about 30 Euro in Germany) and offered hardware (MIPS with 650MHz, 16MiB Flash, 64MiB RAM).

There is already at least one thread here that started discussing a port: Support for UBNT AirCube ACB-ISP But it seems that it hasn't been continued. So I would like to give it a (new) try.

I did some analysis of the hardware system and put together my results here:

There are some odd things in the hardware that might could get interesting later. I'll have to have a look at them as soon as the basic image is running:

  • The LED is not a simple GPIO pin but it has it's own controller connected via SPI (protocol analyzed in the notes)
  • There is a switchable POE Pass Through. I've no idea where such a thing could be integrated into the frontend.

What I'm currently struggling with are the following points:

  • I would like to find out where the RESET button is connected to. Any good idea how to do that while I still have the original firmware? Or is that simpler as soon as I have an OpenWRT running?
  • For the ath79 family of targets I need a device tree. I started a (still incomplete) one in the notes repository (devicetree/qca9533_ubnt_acb-isp.dts - can't post the full link because new users are only allowed to post two links ...). Now I'm struggling with the MAC-Addresses. Some hints how I can find out where the original system get's it's addresses from?
  • I have put a dump of the original flash into the notes repository mentioned earlier and have tried to collect some basic information like the boot log and the content of some interesting files. Do I have to save any more information before I put a OpenWRT image to the AP?

Best regards


1 Like


I think I found out where the mac address is located. I added a chapter in my notes: (Note: It seems the link doesn't fully work. Search for "Finding the Original mac Address").

So my next step will be to try to build and flash an image.

Edit: Added the hint to the link and changed the link to point to a fixed commit.

1 Like


Building a firmware worked. But I'm struggling to flash it via the two "official" paths: The web interface or TFTP recovery. I started to analyze the Ubiquity firmware format to find out something more:

If someone has hints how to build a firmware that can be flashed via web interface or TFTP I would be gratefull.



I don't know how to do it, but since you have a shell access... Had u tried using dd of mtd? If you are overwriting only system and kernel, then if something go wrong, you will still have an option to restore original firmware via tftp, right?

/update: The flash chip is in SOP package, it's easy to find tools for dumping these chips (google: pomona sop clip) and it's better to dump them first.

I don't know if this is helpful, but I hope it is.



Hello kazigk, thanks for the hint. I already did this as one of the first steps after adding the serial port. My method was a little hacky (dumping the flash via U-Boot, post processing the output and converting it from ASCII to binary) but I have a complete image that looks good.

Currently my big problem is to create an image that is accepted by the web interface or (more likely) by U-Boot. I think it is quite possible that it is mandatory to have a signed image for the web interface. But I still hope that U-Boot accepts something with the right checksums. I already did some analysis of the original images (detailed description in my github notes) but U-Boot still refuses the image.

Ubiquiti didn't provide the sources when I asked in January. The answer was a "GPL Source code for airCube is not available for now and we do not have any ETA when it will be available.". I wrote back a friendly reminder that U-Boot is GPL and the support person promised to forward it to the "team" and that they would "check into this".

Nothing happened since than so I'll have to find some other way to create a flash able image. U-Boot is GPL so I don't have a bad consciousness to analyze the binary. But without any symbols or hints regarding the structure, reverse engineering isn't something simple. Maybe I should try to connect a debugger but I haven't found any pins or pads for that and with some bad luck the JTAG could be locked down ...



Bad news: It seems that U-Boot doesn't allow any unsigned binaries. After I have found a bug in my image generation I now receive the following message when trying to upgrade via the urescue command:

Receiving file from
Received 3671068 bytes
Firmware Version: ACB.ar934x
Bad signature!
Firmware check failed! (1)

So most likely there is no possibility to get any new content onto the router via the official channels (web interface or rescue mode).
I'll try to ssh into the original firmware next. If that doesn't work either, the only method is most likely via a serial console via U-Boot which makes it quite hard for a end-user.



I now have updated the flash via U-Boot. Not an ideal way because the case has to be opened to reach the console but still a working one.

OpenWRT is booting and I did some basic tests. The current status is:

  • working:
    • Flash an image via U-Boot console
    • OpenWRT booting
    • Basic WLAN function
    • Switch is set up
    • Ethernet WAN / LAN
    • Upgrade via sysupgrade
    • Reset-Button
  • untested:
    • PoE
    • PoE pass through
    • Doing something more with WLAN than connect one client
  • missing:
    • LED (needs a driver for the SPI-based LED controller)
    • factory upgrade via web IF or TFTP recovery

I think that the current state would be worth integrating into OpenWRT. Currently I've put everything with some unclean commits onto a branch on github:

My next steps would be

  • Rebasing the commits into one clean port commit
  • Test that one on the current master instead of a few weeks old branch
  • Create a pull request
  • Create a wiki page for the device with instructions (can I do that as new user?)

Did I miss something?



Yes, you can! :slight_smile:



Just noted: No I can't. At least not until my patch got merged. The "Create New Dataentry Page" has a required field in "OpenWrt support" which wants to know in which current release the support has been added.

I'll create the page as soon as the patch is merged. Basically I already noted down the information in my notes repository. I'll just have to remove information that isn't relevant.

I created a pull request here: