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

c-mauderer · March 10, 2019, 4:40pm

Hello,

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: https://github.com/c-mauderer/openwrt-Ubiquity-Aircube-notes/blob/9380f83c1/notes/Notes.asciidoc

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

Christian

c-mauderer · March 14, 2019, 8:19pm

I think I found out where the mac address is located. I added a chapter in my notes:

https://github.com/c-mauderer/openwrt-Ubiquity-Aircube-notes/blob/60edeac092fa66324586b119696b2e5e2690b3b3/notes/Notes.asciidoc#finding-the-original-mac-address (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.

c-mauderer · March 16, 2019, 4:48pm

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: https://github.com/c-mauderer/openwrt-Ubiquity-Aircube-notes/blob/0d470cb6883dded06a693faddb4c4088d151866f/notes/Notes.asciidoc#image-format-analysis

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

kazigk · March 19, 2019, 10:27am

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.

c-mauderer · March 19, 2019, 5:34pm

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

c-mauderer · March 24, 2019, 1:33pm

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 192.168.1.5:41751
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.

c-mauderer · March 31, 2019, 10:05am

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:
https://github.com/c-mauderer/openwrt/tree/20190106_aircube

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?

tmomas · March 31, 2019, 1:26pm

Yes, you can!

c-mauderer · March 31, 2019, 6:23pm

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: https://github.com/openwrt/openwrt/pull/1958

kazigk · June 7, 2019, 5:14pm

Hi! I recently bought AirCube ISP. However I cant access the insides. I even broke my credit card (no worry, it was expired) while I was trying to open the case. Would you record a video showing how to open the case or at least take a photo of the clips, please? Thank you in the advance. I appreciate your work

(Sorry for my english, if it's bad)

/edit: I know that there are photos of clips location on your GitHub repo, but I still don;t know how I can pry the clamps

c-mauderer · June 7, 2019, 9:11pm

The case is quite hard to open due to the thick plastic. Some pieces of cardboard can help you a lot. Start on the connector side. See

Sorry for the bad sound quality. I used only a simple compact (photo) camera. Normally I don't do this kind of stuff.
edit: The sound isn't relevant anyway. But please enable subtitles. I added some comments there.

kazigk · June 8, 2019, 8:42am

Thank you! That was very helpful! I'm finally running OpenWRT on my AirCube

c-mauderer · June 8, 2019, 8:58am

No problem.

Please note that I'm still working on the LED. I already have a driver but there is a problem with the SPI speed: https://github.com/openwrt/openwrt/pull/2080

Most likely another kernel patch will be necessary. So it still needs some time.

kazigk · June 9, 2019, 3:38pm

Oh, I see. But the LED can be set to on, without dimming transition, so I'm fine with it

VLANs on eth0 (wan port) are working correctly, I can set up multiple Wi-Fi networks. They are the only ones functions that I need and original firmware doesn't support it.

Finally I have elegant access point (even ap/router must be elegant or hidden behind the wardrobe if you're living together with a girlfriend >_<) that is useful for me

Please write to me if you need a build server or hosting for this project, I can give you a linux container or virtual machine on my home server

c-mauderer · June 9, 2019, 3:59pm

That should be possible as soon as the patches from the pull request are applied. But currently still every now and then a write goes wrong because the SPI is too fast. So blinking won't work yet.

Nice to hear that it is useful.

Thanks for the offer. But I wouldn't know why I personally would need one. The base support is already accepted in OpenWRT and therefore the images are built using the official build structure. If you want to donate something to the project please contact the official team. I'm not really connected to OpenWRT. Just wanted to run it on my access point

kazigk · June 9, 2019, 4:20pm

For me, setting the LED to always on (it was like it by default) works fine even now, because I built OpenWRT from "20190525_aircube_led" branch in your repository.

One question is bothering me. I'm planning to buy AirCube ISP AC. Since this router is using exactly the same firmware file as AirCube ISP, then also the same OpenWRT image should work on AC version. (Maybe except for 5GHz radio, but I can add support for this by simply installing packages that are providing drivers for it). Am I right?

c-mauderer · June 9, 2019, 4:39pm

OK yes. On that branch switching the LED on works (most likely almost every time). Only if you want to do something more like blinking with network traffic, you will get some odd effects.

I had a look at the photos in the FCC documents some time back and there is an extra radio chip for 5GHz in there. So most likely it is necessary to adapt the device tree files for 5GHz to work. Maybe it's necessary too to find out where the calibration data or similar information for the extra radio are. So I'm not sure whether it is enough to just install a driver package.

Snap · August 10, 2019, 8:14am

Hi, I've been experimenting with the Aircube following your tutorial.

Console access works, and afterward I started experimenting with enabling ssh.

Dropbear does not start at all, but by running

/usr/sbin/dropbear -RE

from the console, key generating is started and then after running

ssh ubnt@192.168.1.1

from the computer you have ssh login.

To do it by config file in the web ui, I did a bit of rework of both the 'firewall' file and the 'dropbear' file.

I already found that the config file is in tgz format, so after extracting it I changed first 'dropbear' into this

#!/bin/sh
/usr/sbin/dropbear -RE

and then in 'firewall' I edited in this segment

config include 'ubnt'
	option type 'script'
	option path '/etc/config/dropbear'
	option family 'any'
	option reload '1'

Then I tgz the file and uploaded it. SSH will now be available even after reboot. (Does run two instances for some reason.)

After testing your firmware update script I found out that the error in /etc/fw_env.config is caused by being logged in as ubnt and not root.

which means that when this line is trying to be run

echo "/dev/mtd1 0x0 0x10000 0x10000" >> /etc/fw_env.config

we get a 'not permitted' error.

So next thing is to try login as root. For now this is as far as I have come.

c-mauderer · August 10, 2019, 8:46am

Hello @Snap,

I haven't really done a lot on the device since the initial port (have been quite busy in the last weeks with work stuff - I hope that I'll soon find some more time for such hobby projects again). Currently I have two open points:

The SPI Bus is too fast for the LED controller. Therefore sometimes switching doesn't work. See https://github.com/openwrt/openwrt/pull/2080, Add OpenWrt support for Ubiquity AirCube ISP (UBNT ACB-ISP) and https://marc.info/?l=linux-spi&m=156018623100799&w=2.
I haven't been able to install something without opening the case. See https://github.com/c-mauderer/openwrt-Ubiquity-Aircube-notes/blob/master/notes/Notes.asciidoc#searching-for-alternative-flashing-methods for my current notes regarding that and Ubiquiti airCube: Alternative installation method - problems when writing U-Boot environment for some forum post.

I assume that you are working on the part 2?

In that case: If I remember correctly, the original firmware doesn't have a "root" but they renamed it to ubnt. Try to have a look at the user id.

Currently I have the following impression: All commands that want to do anything with the mtd work when executed from a shell on the serial port. But the same commands seem to give a "not permitted" error as soon as they are executed from a ssh, via webserver or in a startup script. I have never found out why.

Please tell me if you find out something more or if I can help with anything. It's still nagging on me that I never got that working.

Snap · August 10, 2019, 9:13am

Hi @c-mauderer,

yes, I'm looking into number 2, install without physical opening of the case which is my intention.

The LED controller is not my cup of tea, so that I leave for somebody more competent.

And you're right about 'ubnt' being the replacement user for 'root', so the investigation continues into what is really going on here.

I also have a UBNT ACB-AC lying around which might be used for testing if I can get the ISP version to behave. Opening the Aircube was not a fun experience.