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
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.
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
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 
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?
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.
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.
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.
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.
I don't think that it needs that much. Only a bit of time. Like I said: I haven't found enough in the last weeks. But I hope that I'll continue that work soon.
Would be great if you find something. Again: Let me know if I can help with anything.
From what I've seen the AC shouldn't be too much different. Most likely it needs only some adaption of the device tree file - at least if the drivers for the 5GHz chip set are already there.
Hi @c-mauderer,
after a lot of headscratching I now have a way of flashing. Beware that this has only been tested once, and needs more testing.
After some searching I found the routine for the Nanobeam-AC that does it by patching 'ubntbox' so that the signature check is skipped.
A few hours with Ghidra and then the same result for ACB-ISP is to change byte 6016 into 10, first scp the file /sbin/ubntbox to your computer and then edit with hexedit and save it. Then scp the file to ubnt@192.168.1.1:/tmp/
So first problem solved, next generate file that can be used for flashing.
What I did then was to try several things, I'm not sure if everything I did is needed though.
I changed generic-ubnt.mk file in openwrt to this:
define Device/ubnt-acb
$(Device/ubnt)
UBNT_TYPE := ACB
UBNT_CHIP := qca9533
UBNT_BOARD := ACB
UBNT_VERSION := 2.5.0
ATH_SOC := qca9533
endef
define Device/ubnt_acb-isp
$(Device/ubnt-acb)
DEVICE_MODEL := airCube ISP
UBNT_BOARD := ACB-ISP
IMAGE_SIZE := 15744k
IMAGE/factory.bin := $$(IMAGE/sysupgrade.bin) | mkubntimage-split
endef
TARGET_DEVICES += ubnt_acb-isp
I changed mkfwimage.c in openwrt and added this under "WA" definition:
{
.name = "ACB",
.fw_layout = {
.kern_start = 0x9f050000,
.kern_entry = 0x80002000,
.firmware_max_length= 0x00F60000,
},
.sign = true,
},
The end result was to see if openwrt would generate the image file and build it like for Nanobeam-AC, but somehow it didn't do that. I still had the normal file so ubntbox didn't want it.
So I then had to generate the file by hand:
dd if=openwrt-ath79-generic-ubnt_acb-isp-squashfs-factory.bin of=old1 bs=1024k count=1
dd if=openwrt-ath79-generic-ubnt_acb-isp-squashfs-factory.bin of=old2 bs=1024k skip=1
./openwrt/build_dir/host/firmware-utils/bin/mkfwimage -B ACB -v ACB.ar934x.v2.5.0.be3e459.190520.1449 -k old1 -r old2 -o TEST.bin
I used the same version info as for the original firmware so that ubntbox likes the file.
Then scp the TEST.bin file to ubnt@192.168.1.1:/tmp/
I have only had time to test the update via console, but it should work via ssh.
Anyway, login to aircube, and run:
/tmp/ubntbox fwupdate.real -m /tmp/TEST.bin
Of course to get ssh access you need to edit the config file and upload it via the web interface.
This is tested on v2.5.0 of the original AirCube firmware.
Good luck and hopefully it works for you to, I will test more later.
Hello @Snap,
that sounds great. I don't think that I'll have much time this week to test it. But I'll definitively do that on the weekend.
I didn't know Ghidra. Looks like a tool that I should think about adding to my toolbox. Great work finding the right byte to change.
So basically the necessary steps are:
ubntbox so the signature check is skippedPoint 1 should be somehow possible with the tools already provided by OpenWRT. I analyzed the image quite thoroughly. So I hope that I will be able to help with that. Again: Most likely not before the weekend.
For 2: There is a dd on the original firmware (at least on 1.1.2). That could be used to change the file in a script. 3 could be put in a script too. So maybe it is possible to let the OpenWRT build system create a hacked configuration that injects all necessary commands.
Best regards
Christian
Hi @c-mauderer,
Today, I checked to see if the steps I used in the weekend could be used on an Aircube without console cable.
Uploading config to get ssh running worked straight away.
SSH access takes about a minute on the first try, I recommend reboot after config upload since dropbear sometimes crashes when trying to login in without doing that.
Using scp to transfer modified firmware and ubntbox works also.
And then failure... updating doesn't work with patched ubntbox as it is right now. It spits out an error message:
sh: /bin/updatefix.sh: not found
Could not open mtd device: /dev/mtd2
Instead of:
sh: /bin/updatefix.sh: not found
Writing 'kernel ' to /dev/mtd2(kernel ) ... [%100]
Writing 'rootfs ' to /dev/mtd3(rootfs ) ... [%100]
Writing 'extras ' to /dev/mtd0(u-boot ) ... [%100]
Done
So why did it work this weekend on my console aircube? I don't know.
Investigation continues, looks like a ghidra job ...
Regarding that part from your older post: Most of the changes look fine. But if you use make V=s you'll see the error message ERROR: Invalid baord name 'ACB-ISP' during building the image. If the UBNT_BOARD is removed from the ubnt_acb-isp everything works fine and the header of the openwrt-ath79-generic-ubnt_nanobeam-ac-squashfs-factory.bin file looks good.
Where I'm not entirely sure is the .sign = true part. From a quick look at the mkfwimage.c sources it seems that there won't be added a real signature and the CRC will be skipped too. Most likely that could be added later by a special sign tool. I'm not sure whether your manipulation of the ubntbox would ignore both parts (signature and CRC).
That sounds quite like the same bug that I always received. But maybe there could be another approach: With your change it should be possible to upload an unsigned image. So maybe this could work:
/tmp) - possible due to the OverlayFSThis would allow the tools to run mostly in their normal environment. Maybe with this it's possible to avoid the mtd2 bug.
By the way: You noted that you can quite easily revert to the original firmware via U-Boot to re-try again on the same system: https://openwrt.org/toh/ubiquiti/ubiquiti_aircube_isp#back_to_stock_firmware
Hallo,
ich hätte eine Anfrage für ein kleines bezahltes Projekt den AirCube ISP betreffend. Besteht vielleicht die Möglichkeit das wir uns ausserhalb des Forums mal unterhalten könnten?
Danke und liebe Grüße,
Christoph
Hallo Christoph,
ich schick dir eine PM mit Kontaktdaten. Es kann aber gut sein, dass so etwas über meinen Arbeitgeber laufen muss, da ich dort im etwa gleichen Bereich aktiv bin. Wir finden da aber sicher eine Lösung.
Bitte auch beachten: Ich bin kein OpenWRT Maintainer. Ich habe nur einen einzelnen Patch geschrieben. Je nach Aufgabe gibt es eventuell geeignetere Ansprechpartner. Aber auch das können wir offlist klären.
Grüße
Christian
Hi,
I was just looking to see if there was any movement on the Aircube. I'm really interested in getting it working, is there anything i can do to contribute to the progression of this?
Thanks
Hello @tamdenholm,
from my point of view there are two open points for the ACB-ISP:
If you want to run it on an AirCube (without ISP) it would be necessary to find out which drivers are necessary and where calibration data for these drivers are. Then it should be a matter of adapting the device tree.
For me that project has currently a quite low priority. I can put software on the Cube via a serial console and the device is in a room where the blinking LED isn't disturbing me. So I'm happy to help with information or tests. But I have some other hobby projects that have a higher priority so I'm currently not putting a lot of time into it.
Best regards
Christian
Well the ability to load the firmware via the web interface would be the biggest win for me. As ideally i would like to use multiple of these aircubes in a commercial environment, so having to open 10-20 of them to load openwrt would be a nightmare.
Is there any kind of bounty i could offer to make this a priority, either as a consultancy fee or a donation to openwrt? (Happy to do both).