Installing OpenWrt on UniFi nanoHD

Installing and Using OpenWrt
#8

I've managed to build an image from the revision of David's commit, it is based on kernel 4.14, but unfortunately my nano don't like it...

latest:
u-boot legacy uImage, MIPS OpenWrt Linux-5.4.71, Linux/MIPS, OS Kernel Image (lzma), 2480450 bytes, Fri Oct 16 13:29:48 2020, Load Address: 0x80001000, Entry Point: 0x80001000, Header CRC: 0x30FA975F, Data CRC: 0x69149EA8
my:
u-boot legacy uImage, MIPS OpenWrt Linux-4.14.172, Linux/MIPS, OS Kernel Image (lzma), 2016612 bytes, Tue Mar 10 20:54:46 2020, Load Address: 0x80001000, Entry Point: 0x80001000, Header CRC: 0x807D09BF, Data CRC: 0xE9DFECFA

EDIT
I made a dump from the originally installed firmware and file utility is not able to recognize it (described as data). I was wondering if it may be the new uImage instead of legacy one :thinking:

#9

The new bootloader may be requiring signed or encrypted firmware, in which case you'll have to downgrade the bootloader.

Is it possible to open the case of these and make a serial connection?

#10

Looks like opening the case is not possible. According to the video I found it is glued, so opening may void my warranty.

I have topic opened on Ubiquity support about downgrading under minimal version. One way I see is to extract boot loader from official image (for example with this tool: https://github.com/aliosa27/ubnt-mkfwimage author may add nano support soon) and dd it manually. Or even made a custom build?

#11

Yesterday I took the risk and dd–ed the bootloader with 3.29 version together with snapshoot image from commit 4c8446bf39de99990847eb4bc7744e25835a34f5, which was supposed to more or less work.

Unfortunately the result was boot error (fast blinking white led). It is "slightly better" then before where loading this image was resulting the device to switch onto the TFTP mode. Exactly same happens (boot error) when launching the official 3.x image.

I assume that there is some slightly difference in the hardware, that is not correctly reflected in the DTS.

#12

Same issue here, it only boots into TFTP mode (I think, blue/white blinking) with an OpenWRT image dd'ed to mtd as per the initial commit. Downgrading to v3.9.27 yields a fast white blinking LED.

Did you figure out why that happens? Any solution?

#13

@knacky
In the now closed thread Flashing OpenWrt to Ubiquiti UniFi AP (stock flash ver >= 4.0.15) - #7 by knacky it sounds like you found a way? Can you be more specific please?

Does it boil down to:

  1. Use fwupdate.real to downgrade the bootloader
  2. Write an OpenWrt image without reboot using mtd write

?

#14

fwiw downgrading using fwupdate.real doesn't work for me:

UAP-nanoHD-BZ.5.43.23# fwupdate.real -d -c /tmp/BZ.mt7621.v3.9.27.8537.180317.1220.bin 
check = 1
verbose = 1
keep_running = 0
write_flash = 0
imagefile = /tmp/BZ.mt7621.v3.9.27.8537.180317.1220.bin
Found mtd block: /dev/mtd0(u-boot)
Found mtd block: /dev/mtd1(u-boot-env)
Found mtd block: /dev/mtd2(Factory)
Found mtd block: /dev/mtd3(EEPROM)
Found mtd block: /dev/mtd4(bs)
Found mtd block: /dev/mtd5(cfg)
Found mtd block: /dev/mtd6(kernel0)
Found mtd block: /dev/mtd7(kernel1)
Got U-Boot variable: mtdparts = mtdparts=mt7621-nor0:384k(u-boot),64k(u-boot-env),64k(Factory),64k(EEPROM),64k(bs),1024k(cfg),15552k(kernel0),15552k(kernel1)
Adding U-Boot partition: u-boot BFC00000 00060000
Adding U-Boot partition: u-boot-env BFC60000 00010000
Adding U-Boot partition: Factory BFC70000 00010000
Adding U-Boot partition: EEPROM BFC80000 00010000
Adding U-Boot partition: bs BFC90000 00010000
Adding U-Boot partition: cfg BFCA0000 00100000
Adding U-Boot partition: kernel0 BFDA0000 00F30000
Adding U-Boot partition: kernel1 C0CD0000 00F30000
Calculating flash size:
Adding block: /dev/mtd0("u-boot") - size: 00060000
Adding block: /dev/mtd1("u-boot-env") - size: 00010000
Skipping block /dev/mtd2("Factory") - size: 00010000, artificial: 0, unallocated: 0, writeable: 0(WRITEABLE: 400, flags: 800)
Skipping block /dev/mtd3("EEPROM") - size: 00010000, artificial: 0, unallocated: 0, writeable: 0(WRITEABLE: 400, flags: 800)
Adding block: /dev/mtd4("bs") - size: 00010000
Adding block: /dev/mtd5("cfg") - size: 00100000
Adding block: /dev/mtd6("kernel0") - size: 00F30000
Adding block: /dev/mtd7("kernel1") - size: 00F30000
Total flash size: 02000000
Flash start: BFC00000
Flash end: C1C00000
Header MAGIC 'UBNT'
Current: BZ.mt7621_5.43.23+12533.201222.2019
New ver: BZ.mt7621.v3.9.27.8537.180317.1220
Invalid version 'BZ.mt7621.v3.9.27.8537.180317.1220'
#15

As stated before, most likely there is hardware changes between versions. Support stated that it is not true, and "version lock" is just because. But after force downloading the boot loader device is not booting.

#16

Sorry for the late reply @dhewg. I downgraded the bootloader as follows:

  1. Download v3.9.27 firmware from Ubiquiti site
    Ubiquiti - Downloads

  2. SCP the firmware file to /tmp on the nanoHD

  3. Run the following command to downgrade the bootloader to the one included in the v3.9.27 firmware file:
    fwupdate.real -m /tmp/BZ.mt7621.v3.9.27.8537.180317.1220.bin

  4. When it reboots and comes back up, follow the installation instructions in the git commit link in post #1 of this thread to install OpenWrt.

#17

I just tried the above methods to install OpenWRT on the NanoHD. It did not work.

I experienced the same roadblocks as the users above. It turns out you cannot simply downgrade the bootloader as described by @knacky, the result is "Invalid version". The lowest firmware I could go was 4.3.21.xxx. All others failed when using the SCP method for transfer and SSH for fwupdate.real.

I also tried older firmware with TFTP, the result failed with rapid flashing white. Nothing that I tried worked to install an earlier firmware (and specifically the firmware v3.9.27.xx suggested in the commit).

I also YOLO tried with the snapshot, but the same happened as @dhewg mentioned, it would boot to TFTP.

I just posted this to confirm that downgrading doesn't work on these recently purchased nanoHD. I ended up using UniFi for now (send help lol :wink: ).

What's the next step?

#18

Then, sadly, it sounds as though newer firmware versions shipping on current stock are prohibiting u-boot downgrades.

#19

Hey guys,

i opened one of my Nano HD's. They are just clamped together not glued.

There is a 4 Pin Header on the PCB which will give you a serial terminal.

Flashing the 3.9.27 Firmware does start the nano and will after some time even start the ssh server (Even though the LED is fast flashing white). But you cannot login to the ssh server.
However with the Serial console you can copy the openwrt firmware image to the nano with netcat or something like that. Then you can flash like it is said in the git commit and openwrt will start fine.

But... i had this idea of extracting the u-boot bootlader from Version 3.9.27, copy it to my pc, then upgrade to a recent firmware (5.43.36), login with ssh, flash like said in the git commit, AND dd the old u-boot bootlader into /dev/mtd0. Guess what... Bricked my nano. So don't be like me and dd your u-boot manually :smiley:

2 Likes
#20

I forgot something:

When flashing the openwrt Image like PsyLive said (4.321.xxx) it will say "Bad CRC" when booting up and will fall back to tftp mode.

1 Like
#21

I just installed openwrt 21.02.0-rc3 back onto my NanoHD. It previously ran stock firmware v5.43.36.

My steps were:

  1. 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.
  2. 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.
  3. 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.

#22

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:

  1. I installed Debian 9 (Oldstable/Stretch) on an old laptop.
    a) Only this version comes with mongodb-server – probably due to a license change
  2. I Installed the following packages as dependencies: binutils curl jsvc mongodb-server
  3. I installed lighttpd to later provide the firmware to the AP
  4. I downloaded UniFi Network Controller 5.14.23 for Debian/Ubuntu Linux and UniFi Cloud Key and UniFi firmware 3.9.27 for UAP-nanoHD
    a) Newer versions of the UniFi Network Controller seem to enforce a UniFi online account
    b) Download here: https://www.ui.com/download/unifi/default/default/unifi-network-controller-6171-debianubuntu-linux-and-unifi-cloud-key
  5. 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
  6. I connected AP and laptop to a separate, offline router to avoid UniFi spying on my local network
  7. I installed UniFi Network Controller on the old laptop
    a) dpkg -i unifi_sysvinit_all.deb
  8. I opened the UniFi controller in the browser (localhost:8080 or localhost:8443) and clicked through the setup process
  9. I clicked on "devices" on the left-hand icon bar and waited until the AP popped up and adopted it
  10. 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
  11. (optional?) I used the end of a toothpick to hold down the reset button of the AP for > 5s which triggers a factory reset

Then I simply followed the steps outlined in the initial commit to install OpenWrt 21.02.0 RC3.

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 :slight_smile:

#23

Fantastic set of instructions.

Here's what worked for me:

  1. Make sure I have ssh login enabled to the nanohd (with the appropriate ssh keys)

  2. Upgrade the nanoHD using the upgrade URL in the web config interface (or the app) to downgrade using this URL: https://dl.ubnt.com/unifi/firmware/U7NHD/3.9.27.8537/BZ.mt7621.v3.9.27.8537.180317.1220.bin

  3. scp the relevant ramips sysupgrade file to the device.
    e.g.
    scp openwrt-21.02.0-rc3-ramips-mt7621-ubnt_unifi-nanohd-squashfs-sysupgrade.bin admin@nanohdipaddress:/tmp/

  4. Follow git instructions 2-4 from https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4c8446bf39de99990847eb4bc7744e25835a34f5

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

1 Like
#25

2 posts were split to a new topic: Performance of UniFi nanoHD

#26

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.

  1. SSH'd into the AP using the default address and user/password.
    Downgraded the firmware to 3.9.27 using fwupdate.real -m

  2. reboot and ssh back into the AP which now running 3.9.27.

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

#27

I'm confused, why are people using ipq806x when the nanoHD is mt7621? Was there a hardware revision?

1 Like
#28

If you refer to the link posted previously for the downgrade by @satmandu, I think it's a copy and paste mistake.

1 Like