I'm trying to install openwrt on my new Unifi 6 LR, but having some difficulties. I was following the instructions here: https://openwrt.org/toh/ubiquiti/unifi_6_lr. The first time I tried it I used the v2 image, and after rebooting the AP eventually got to a blue light, but I couldn't find any way to connect to it, neither by trying a default ipv4 address like 192.168.1.1 or 192.168.1.20, nor a ipv6 link local address (it wasn't responding to ipv6 pings on ff02::1). After that I was able to hold the reset button, use the tftp mode to reload the stock firmware, and follow the instructions again, this time using the v2 image. However, now whenever I power it on it immediately sets the led to white, and nothing else seems to happen. I still cannot connect to it, and holding the reset button seems to do nothing. Does anyone have any ideas of what I can do short of opening it up and getting at the serial connection?
Have you tried the TCP dump instructions in the failsafe mode section?
There doesn't appear to be any kind of traffic originating from the AP, and it doesn't respond on the mac address based link local address I used to connect when it was running the stock unifi firmware. Though I am connecting through a PoE switch (I don't have an injector), so not 100% sure the switch isn't messing with something, though I'm pretty sure it shouldn't be.
It's strange you can't get into the tftp mode. As far as I'm aware, this is taken care of by the bootloader and openwrt doesn't overwrite that. Are you sure you aren't able to get into it?
Having a serial connection is definitely handy just generally. It's got me out of a few jams with lots of hardware.
Yeah, I'm kinda confused. Unfortunately it seems opening this up is going to be a huge pain.
Now the second time I went through the instructions I'm realizing I think I did this step:
$ echo "5edfacbf" > /proc/ubnthal/.uf
which now that I'm reading them again mentions if above a certain firmware version, which I think may not have been the case, not sure if that is what caused things to go haywire. Even still I'd have assumed the bootloader would still be able to get into tftp mode.
But yeah, like I said, I cannot seem to get the device into any kind of recovery/tftp mode. The first time I had tried to install openwrt it worked fine, I was able to hold the reset button and it went into tftp mode just fine. But now, as soon as it gets power the led goes to white, and no amount of holding the reset button does anything at all.
I'm not 100% but I can't imagine that command would cause this issue.
You should be able to get into tftp, the bootloader should be intact if you followed those instructions.
Someone else might have some better ideas.
I just read the information regarding opening the case. I see why you're reluctant!
Yeah it didn't seem like it'd be the kind of thing to basically brick things, but I don't know enough to be sure. I'm wondering if I somehow damaged the reset button or something, but I really can't imagine how I'd have done that already.
And I just went back over the terminal history to double check and as far as I can tell I did follow the instructions, with the correct partitions etc so I don't know what happened.
Could you post your terminal history here? Might be useful. You should obfuscate any sensitive information.
$ ssh -oHostKeyAlgorithms=+ssh-rsa ubnt@<link local ipv6 addr>
ubnt@<link local ipv6 addr>'s password:
BusyBox v1.25.1 () built-in shell (ash)
___ ___ .__________.__
| | |____ |__\_ ____/__|
| | / \| || __) | | (c) 2010-2022
| | | | \ || \ | | Ubiquiti Inc.
|______|___| /__||__/ |__|
|_/ https://www.ui.com
Welcome to UniFi U6-LR!
********************************* NOTICE **********************************
* By logging in to, accessing, or using any Ubiquiti product, you are *
* signifying that you have read our Terms of Service (ToS) and End User *
* License Agreement (EULA), understand their terms, and agree to be *
* fully bound to them. The use of SSH (Secure Shell) can potentially *
* harm Ubiquiti devices and result in lost access to them and their data. *
* By proceeding, you acknowledge that the use of SSH to modify device(s) *
* outside of their normal operational scope, or in any manner *
* inconsistent with the ToS or EULA, will permanently and irrevocably *
* void any applicable warranty. *
***************************************************************************
U6-LR-BZ.6.0.21# ls /proc/
1 2561 3031 3420 564 713 919 fs modules stat_interval version
10 2562 3054 351 567 729 buddyinfo gpio mounts svs vmallocinfo
11 2563 3061 360 584 737 bus interrupts mtd sys vmstat
12 2564 3063 361 6 738 clkdbg iomem mtkcooler sysrq-trigger wdk
13 2565 3064 3615 635 7474 cmdline ioports mtketh sysvipc zoneinfo
1362 2566 3065 3619 640 7495 config.gz irq mtktz thermlmt
1364 264 3066 419 645 7496 consoles kallsyms net thread-self
1556 2663 3067 434 650 7498 cpuinfo kmsg nfbypass timer_list
2 3 3068 5 655 7562 crypto kpagecount pagetypeinfo tty
227 3021 3069 546 660 7588 device-tree kpageflags partitions ubnt_frame_id
229 3023 3071 549 665 7589 devices loadavg rtk_gsw ubnt_peek
230 3024 3072 552 670 8 diskstats locks self ubnt_rx_task
232 3025 3074 555 675 854 driver loglevel slabinfo ubnthal
234 3027 3075 558 680 865 execdomains meminfo softirqs uid_time_in_state
2560 3028 3130 561 7 9 filesystems misc stat uptime
U6-LR-BZ.6.0.21# echo "
U6-LR-BZ.6.0.21# ls /proc/ubnthal
board status system.info
U6-LR-BZ.6.0.21# ls /proc/ubnthal/.uf
/proc/ubnthal/.uf
U6-LR-BZ.6.0.21# cat /proc/ubnthal/.uf
cat: read error: I/O error
U6-LR-BZ.6.0.21# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00001000 "Preloader"
mtd1: 00020000 00001000 "ATF"
mtd2: 00060000 00001000 "u-boot"
mtd3: 00010000 00001000 "u-boot-env"
mtd4: 00040000 00001000 "Factory"
mtd5: 00010000 00001000 "EEPROM"
mtd6: 00010000 00001000 "bs"
mtd7: 00100000 00001000 "cfg"
mtd8: 01ee0000 00001000 "kernel0"
mtd9: 01ee0000 00001000 "kernel1"
U6-LR-BZ.6.0.21# echo "5edfacbf" > /proc/ubnthal/.uf
U6-LR-BZ.6.0.21# dd if=/dev/zero bs=1 count=1 of=/dev/mtdblock6
1+0 records in
1+0 records out
U6-LR-BZ.6.0.21# dd if=
U6-LR-BZ.6.0.21# ls
cfg dropbear_dss_host_key v1.bin
U6-LR-BZ.6.0.21# dd if=v1.bin of=/dev/mtdblock8 status=progress
BusyBox v1.25.1 () multi-call binary.
Usage: dd [if=FILE] [of=FILE] [ibs=N] [obs=N] [bs=N] [count=N] [skip=N]
[seek=N] [conv=notrunc|noerror|sync|fsync] [iflag=skip_bytes]
Copy a file with converting and formatting
if=FILE Read from FILE instead of stdin
of=FILE Write to FILE instead of stdout
bs=N Read and write N bytes at a time
ibs=N Read N bytes at a time
obs=N Write N bytes at a time
count=N Copy only N input blocks
skip=N Skip N input blocks
seek=N Skip N output blocks
conv=notrunc Don't truncate output file
conv=noerror Continue after read errors
conv=sync Pad blocks with zeros
conv=fsync Physically write data out before finishing
conv=swab Swap every pair of bytes
iflag=skip_bytes skip=N is in bytes
N may be suffixed by c (1), w (2), b (512), kB (1000), k (1024), MB, M, GB, G
U6-LR-BZ.6.0.21# dd if=v1.bin of=/dev/mtdblock8
17920+1 records in
17920+1 records out
U6-LR-BZ.6.0.21# dd if=v1.bin of=/dev/mtdblock9
17920+1 records in
17920+1 records out
U6-LR-BZ.6.0.21# sync
U6-LR-BZ.6.0.21# Connection to <link local ipv6 addr> closed.
Where v1.bin was https://downloads.openwrt.org/releases/22.03.3/targets/mediatek/mt7622/openwrt-22.03.3-mediatek-mt7622-ubnt_unifi-6-lr-v1-squashfs-sysupgrade.bin that I had scp'd over.
The only other difference I can think of the second time was that instead of using the reboot command like I did the first time, after a minute when I came back to it, I pulled the plug and plugged it back in.
After reading this thread
It looks as though the tftp recovery can use different IP addresses to the default once openwrt is flashed. It won't respond to ping either.
Can you try the following
-
Make sure your AP is powered on, and has one available ethernet port.
-
Press and hold the Reset button. Do not release it until step 4.
-
While continuing to press the Reset button, connect your computer to the available ethernet port of the AP.
-
Continue holding the Reset button until the light begins flashing white > blue > off as indicated in our LED Status Guide. This indicates your device is ready for TFTP Recovery and you can release the button.
-
Set a static IP address on your computer to communicate with the AP
Static IP: 192.168.1.25
Subnet: 255.255.255.0
- Run nmap to determine the routers IP address
sudo nmap -sn 192.168.1.*
- Send firmware using tftp to the discovered IP address
Can you post the output of nmap please? Hopefully you can see the host during the scan!
Yeah, I've tried that already, haven't found any way to get the AP into the TFTP mode, the light won't do anything other than stay on at a constant white, not matter how long I hold the button down (I've tried as long as over 1 minute). And I've used nmap+tcpdump to verify it's not just leaving the led alone but actually in TFTP mode - the AP simply will not respond to ARP at all for any address in 192.168.1.0/24, nor respond to ipv6 pings on ff02::1.
Hmm, one other thing I did just notice is that when I first powered it up it had U6-LR-BZ.6.0.24 as the installed firmware, but when I flashed it back after the first attempt, I used the U6-LR-BZ.6.0.21 firmware linked on the device page https://openwrt.org/toh/ubiquiti/unifi_6_lr. Again that doesn't seem like that should brick things either though, and it did boot into that firmware after I flashed it. But I didn't test the TFTP mode after that but before trying to install openwrt again. Oh I may have also tried to tftp the openwrt image first too - not sure if maybe that could have overwritten things it shouldn't have.
And you are powering the AP on (i.e connecting ethernet) while the button pressed? The LED should never go to steady white between power-on and tftp recovery mode.
Hmm, that might cause problems I guess. I believe this will downgrade the bootloader as well. And with the all the hardware revisions out there, there's no guarantee that an older than original bootloader will work properly. But the reset button and LEDs should still work, so even if my far fetched theory is correct, it can't explain the symptoms
Yeah I tried holding the reset button while powering on, and still the led goes steady white the instant it gets power.
I can't think of much more to try aside from cracking it open to get at the serial pins. Definitely going to try that eventually but might be a while before I do because of how much of a pain that seems to be.
Ok, got ahold of another unifi 6 lr, and this time it seems it worked better than before at least - the new one seems to boot normally as it goes through a phase of blinking the led white, and then settles on blue, and I can still get back into tftp mode. However, once it's booted I still cannot access it at all which is confusing, trying a ping scan of 192.168.1.* doesn't find anything and neither does pinging ff02::1.
Interestingly I noticed that this one came with firmware version 6.0.25, and neither 6.0.24 (what came on the last one) nor 6.0.25 are available for download from ubiquiti. When I initially flashed this unit with the v1 openwrt firmware, it seemed not to be working, though perhaps it was just in the same state of "booted" but not responding at all, and just not controlling the led because my unit is probably v2. I went back into tftp mode, flashed the latest firmware, then flashed the v2 openwrt firmware and got to the state described above. Definitely better than completely bricked like the first one, but not sure why it wouldn't respond to anything, unless I'm missing something about what it's default IP address is or something.
I also do not see the udp packet mentioned here https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset. Additionally while it seems I can trigger failsafe mode (and get the faster blinking during boot), it never seems to finish booting in failsafe mode and just continues the fast blinking (though I'm going to leave it for a little while longer and see if maybe it's just being slow to boot or something).
I've also just tried the initramfs kernel image in addition to the sysupgrade image mentioned in the install instructions, and both result in the same behavior of not responding to anything on the ethernet port. Now I'm wondering if I still need to open at least one of these up since it seems like this one at least would for sure have useful info on the serial port - e.g. some logs about why ethernet isn't working or something. Might have a chance to get one open in the next few weeks so we'll see.