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).
I can't really do paid open source work in that area because it would be competitive work to my day job. And for 10 to 20 boxes doing it at my day job wouldn't be a realistic price. Besides that I wouldn't be able to give any guarantees that it even is possible.
I'm not really an OpenWRT developer so I'm not sure how donations to the project would be handled.
@Snap: You did put quite some time into it already. Are you interested to continue the work for a bounty like @tamdenholm suggested?
If Snap doesn't show interest I might be ready to put some quite limited time into it just because you asked nicely and I'm always happy to see that something I did is useful 
. But please note that I currently have a really high priority hobby project that has the potential to eat up quite a lot of time in the next weeks. So please don't expect a fast progress.
Sorry, I don't have available time for this type of job either.
But I did test a bit more of my procedure for flashing the aircube. And something fishy is going on. Because if you try to do everything by serial console, then it works as intended and the aircube is flashed.
But if you try doing the same procedure by ssh, it fails and complains about not unlocking flash...
So it looks like there is some kind of check to see how you are executing the flash command.
And thats how far I have come yet. Maybe I will have time to dig more at a later time, but my job has priority these days.
Well i do appreciate both of your responses.
@c-mauderer if you do find time at your convenience to continue to work on this, i'd be happy to help in my very limited understanding. I'm a web developer, but very little hardware experience.
I'd also happy to honour the bounty regardless. Whether thats a donation to any one of your projects, an open source project, or even a charity.
I have managed to get a small step forward:
I created a configuration for Firmware version 2.5.0 that allows to call a script to mount an overlay file system and patch ubntbox like described by @Snap. With that I've been able to upload a file generated with the OpenWRT build system and the web interface told me that it is OK. The bad news is: The file hasn't been flashed. So either my format is still wrong or there is a second check ...
The special config can be found here: https://github.com/c-mauderer/openwrt-Ubiquity-Aircube-notes/raw/344c005032a5f8b4ce9a08c6363d6df08a95c978/upgrade-config/patch_signaturecheck_config_2.5.0.tgz
User is still "ubnt", password is "password".
To generate the OpenWRT firmware image I used the following patch (again based on the work from @Snap): https://gist.github.com/db7a96ef488c74425433821329ed0fd9 (on top of OpenWRT commit 487e0631d00c345b951cc31934e8e83a1e6e7cbe).
Oh, I forgot to add how to use the config:
You might have to reboot the Aircube once after setting the config. I'm not sure whether uhttpd is restarted otherwise. After that a second web server instance is started and the script that patches the ubntbox can be executed by visiting the following url: http://192.168.1.1:8080/lua
Note: No https allowed
The patch is not permanent. You have to do it after every reboot.
If I patch the ubntbox using the script and do a
ubntbox fwupdate.real -m test.bin
via serial console the flashing works. So the image is generated correctly by the OpenWRT build system.
Ah, if called via sysupgrade a ramdisk is used and some signature check fails:
ubnt@airCube-ISP:/tmp# sysupgrade -v -n temp.bin
{
"status": "running",
"timeout": 120,
"frequency": 10,
"magicclose": false
}
Sending TERM to remaining processes ... logd netifd ubusd rpcd
Sending KILL to remaining processes ... ubusd
Switching to ramdisk...
ln: /tmp/root//bin/cut: Read-only file system
Performing system upgrade...
Signature check failed
Upgrade completed
Rebooting system...
Also I managed to get the sysupgrade -v -n temp.bin working when called from console (see latest config in my git repo), it still won't work when called from the web interface. So still no success.
I think I have a trace why it doesn't work: There is a configuration for tomoyo in etc which seems to be a access control system. Tomoyo was new to me so I don't really know the syntax of the configuration files. But it seems that there is a rule that allows /sbin/fwupdate.real to access /dev/mtd* but not any other application. My configuration moved fwupdate.real to tmp because any overlays that I added have been removed during the update. But in the new location, the application isn't allowed to write to the disk. I'll try to find a way around it ...
I think I solved it. It seems that I have chosen a really bad name in my patch script that collided with a name in the sysupdate scripts.
I need someone who is brave enough to test it:
Edit:
I forgot to mention again: The user and password for the config are "ubnt" and "password".
@tamdenholm: It would be great if you could test the config. After that I'll create a pull request for OpenWRT.