I just installed openwrt 21.02.0-rc3 back onto my NanoHD. It previously ran stock firmware v5.43.36.
My steps were:
TFTP v3.9.27 stock firmware into the nanoHD with my pc interface set to 192.168.1.25 and gateway to 192.168.1.20
It should start blinking between blue/white, reboot itself, and stay steady white.
Followed David's instructions
Ran cat /proc/mtd to check if partition mtd4 is labeled "bs", which it was. Ran the last two dd commands, each time it disconnected my session... so don't know if it even worked.
Rebooted the ap, set pc gateway to 192.168.1.1 and I was able to access luci from there.
I have ran openwrt with this ap in the past, so idk if this helps.
I'm posting this for the record or as an alternative method. This is the method I used before even reading this thread; using TFTP sounds a lot easier though!
I started with firmware version 5.x, if I recall correctly and used the UniFi Network Controller to downgrade the firmware:
I installed Debian 9 (Oldstable/Stretch) on an old laptop.
a) Only this version comes with mongodb-server – probably due to a license change
I Installed the following packages as dependencies: binutils curl jsvc mongodb-server
I installed lighttpd to later provide the firmware to the AP
I copied the old firmware BZ.mt7621.v3.9.27.8537.180317.1220.bin to /var/www/html to later provide it to the AP
I connected AP and laptop to a separate, offline router to avoid UniFi spying on my local network
I installed UniFi Network Controller on the old laptop
a) dpkg -i unifi_sysvinit_all.deb
I opened the UniFi controller in the browser (localhost:8080 or localhost:8443) and clicked through the setup process
I clicked on "devices" on the left-hand icon bar and waited until the AP popped up and adopted it
In the device box on the right-hand side (after clicking on the actual AP) I opened the settings tab (gear icon) scrolled down.
In "custom upgrade" or similar and started the upgrade (or rather downgrade) with a URL to my local Lighttpd: http://<LAPTOP_LAN_IP_ADDRESS>/BZ.mt7621.v3.9.27.8537.180317.1220.bin
(optional?) I used the end of a toothpick to hold down the reset button of the AP for > 5s which triggers a factory reset
I was a bit uncertain about using /dev/mtd4 in step 2 and /dev/mtdblockX in step 3. I don't know if it makes a difference to use it with BLOCK or without. I, however, checked that the numbers matched up in /proc/mtd and in the end it worked out well
Set my local ip to something in 192.168.1.x, but not 192.168.1.1, and ssh root@192.168.1.1, and change the ip in /etc/config/network to what I want it to be, and reboot.
Thanks for pointing out the correct url @alexatkinuk !
I just successfully installed OpenWrt 21.02.0-rc4 on a brand new (August 2021) UniFi nanoHD.
Although there is quite of bit of general info for running OpenWrt on Ubinquiti, there is not a lot of device specific info for the nanoHD so I figured I'd share my experiance in the hope that it helps someone.
Right out of the box I connected the ethernet to my laptop with nothing in between other than the POE injector.
SSH'd into the AP using the default address and user/password.
Downgraded the firmware to 3.9.27 using fwupdate.real -m
reboot and ssh back into the AP which now running 3.9.27.
follow the instructions in the original git commit to load OpenWrt, except that I used the 21.02.0-rc4 sysupgrade image.
ok, here I had a problem. when I rebooted it went straight into tftp mode (flashing blue-white-off). Much time and anguish was spent on what turned out to have nothing to do with the device here. Eventually I was able to re-load 3.9.27 over tftp.
Once again, followed the instructions from the original git commit to install OpenWrt 21.02.0-rc4 and reboot. This time it worked and OpenWrt booted up as expected.
A few other details that might or might not be relevant...
This was a brand new device that has never connected to a Ubiquiti controller or the internet.
When I first connected to the device right out of the box, it appeared to be running UAP-nanoHD-BZ.v5.16.0
Later when fighting with tftp mode, I noticed that the internet seems to have no mention that such a version ever existed. It's possible that this is a factory loaded version that gets immediately upgraded if/when connected to normal Ubiquiti setup procedures, but that's just a guess.
I had no problem downgrading this to v3.9.27 and never encountered the flashing white behavior others have run into.
When debugging the first failure (causing it to boot straight to tftp mode) I found it was attempting to boot kernel 1. This is despite having set mtd4 to zero as per the git commit, and the fact that folowing the git instructions writes the OpenWrt image to kernel 1 as well as kernel 0. On the second attempt at loading OpenWrt, it was indeed booting kernel 0 and working correctly.
I hope this is useful for someone who is trying to get their nanoHD working with OpenWrt.
Write the bootselect flag. Otherwise, the device might boot from the wrong partition. Verify the mtd partition used in the command below
is the one labled "bs" in /proc/mtd (as this might change in the future).
dd if=/dev/zero bs=1 count=1 of=/dev/mtd4
Write the OpenWrt sysupgrade to the mtd partitions labeled "kernel0" and "kernel1" then reboot the nanoHD.
Set my local ip to something in 192.168.1.x, but not 192.168.1.1, and ssh root@192.168.1.1, and change the ip in /etc/config/network to what I want it to be, and reboot.
Now the only catch is I can't seem to get 5Ghz to come up on DFS channels.
I got invalid version because it WAS the invalid version as you pointed out.
Now if I could figure out the 5Ghz issue. OpenWRT says disabled if I pick a DFS channel, but even picking 36 it now says it IS up, but my phone can't see the network.
On the plus side, 2.4Ghz is going faster than I've seen in a long time att 77.6Mbit down, trouble is I have up to 720Mbit 5G and 120Mbit load balanced DSL, so I really need 5Ghz to work.
Not in my case, as I was aware of the link being wrong, so I downloaded the correct one since the beginning. I think it has to do with my U-Boot being upgraded and installing such an old version is not allowed.
Official firmware used to do about 800Mbit as I recall, it reduced to 700 then 600 seemingly as the firmware updates came out.
Now of course it might not have been a firmware issue at all, just environmental, but I prefer OpenWRT anyway as I hated running the bloated Unifi Controller. Also how common it is for Ubiquiti to break things, OpenWRT is usually a lot better tested.
Of course the point is moot if I can't even get 5Ghz to work at all.
Yeah for me is more about fighting buffer bloat. I can't use ethernet cable and I have to connect wirelessly an additional AP upstairs. I thought like trying to see if OpenWrt can help a bit with it. I'm not sure, tho'.
There we go, apparently leaving country code in "driver default" disabled DFS. Switched it to GB and its now working, rookie error. Not getting a good link rate though, need to fiddle with the channels.
For the record, on channel 36 at 80Mhz I was getting a respectable 400Mbit down, 120Mbit up but I need to use DFS channels to get 160Mhz.
Agreed, and to be fair once I can get a WiFi 6e AP then 400Mbit would be fine for where I will move the nanoHD to.
I've been using an Honor Router 3 for my fastest clients but had kinda hoped I could get 800Mbit back on the nanoHD so I can stop using that as it blocks some LAN traffic.
So it seems 160Mhz is broken, I've only managed to get it to come up on channel 36 and its slower than 80Mhz only able to do 300Mbit.
However 80Mhz on channel 52 I managed to hit 525Mbit down on my phone, so DFS at least in some fashion is working.
Interestingly my laptop was able to hit 600Mbit down and 336Mbit up using an Intel AX210. Very curious, as on stock firmware my phone (Galaxy S10) would always work much better than my laptop.
Probably not broken. Worst link quality and more noise, as expected with such a wide channel, do not forget that doubling the channel width decreases your signal strength by 30% (-3 dB) hence lower MCS and lower throughput, that not considering the additional noise as I said. I hope you live in an isolated farm in the bushes, otherwise is a mistake going with 160 Mhz channel width!
Its broken as it wont come up on higher channels where it was able to do 600Mbit on stock firmware.
That said, I did another check on my phone on 80Mhz with iperf3 this time and it goes 380Mbit down, 500Mbit up. Before I wasn't using iperf as I've found it a bit quirky, it can produce both lower and higher results than real-world so I prefer LibreSpeed running on my server via the browser.
LibreSpeed on my laptop (Linux) shows 662Mbit down (saw a peak to 700), 590Mbit up, that's honestly not bad for 80Mhz, I'm sure the stock firmware wasn't that fast. Looks like my mums phone is getting a higher link rate upstairs than I've seen before too.
Its only doing 494 down, 419 up in Windows though vs the Honor Router that does just hit 909 Down for the first time ever and 442 up (channel 100 80Mhz WiFi6). Iperf3 shows much slower, which is why I don't trust it as copying a file off my NAS mostly did over 100MB/s confirming LibreSpeed was correct.
as you pointed out.