Unifi 6 LR - anyone got OpenWrt working on brand new ones?

madmacka · February 5, 2022, 9:24am

Just bought 2x unifi 6 LR APs and tried to get openwrt on them. both end up the same way after following the install guide at https://openwrt.org/toh/ubiquiti/unifi_6_lr.

both were flashed with 21.02.1, neither worked completely showing up with only one radio device in luci after the flash (2.4ghz) radio only.

thought maybe id flashed the wrong firmware some how, so double checked and re downloaded the FW from the FW selector. and flashed via luci ( with all check boxes off ) .. this just bricked device number one and had to be recovered using the original FW via TFTP recovery method. i also flashed the second one back to original FW.

on one of the units i tired the process again but using the snapshot version of the Openwrt FW from the firmware selector... this just bricked AP instantly and once again had to go back through the TFTP OEM recovery route. interestingly the devices status LED looked all normal trough out the boot process. just not accessible at all, like wise putting it in openwrt recovery mode also not accessible.

this is my fist problem with openwrt and have been using it well since somewhere in the mid 2000's ( very early versions) so I'm no novice, but nor am i developer or linux guru. I know people a going to scream "logs" but i didn't keep / really look at them during the process and being a royal PITA from beginning to end I'm not keen on going through the process again, just to get logs. i didn't bother as I just generally expect a vanilla install to just work.

my question is , has anyone else more knowledgeable than I very recently picked up a unifi 6 LR had similar problems and found a work around?

Borromini · February 6, 2022, 11:29pm

@madmacka Try downgrading the Ubiquiti firmware and check whether OpenWrt installation instructions talk about a specific OEM firmware. Searching the forum might help show which firmwares worked.

antoninchadima · February 7, 2022, 7:47am

I am using Unifi 6 LR with OpenWrt for a while without a problem.

For the first device flashing, I downloaded the image from the device page. This image doesn't contain Luci, and the LED light after the boot finishes is off.
So I freaked out and tried to roll back with the TFTP method and an original Ubiquity image. I didn't do anything wrong, but there is no way to flash the device using TFTP after flashing OpenWrt. Gladly I did find out that I can ssh into the device where a standard OpenWrt is running. Afterward, I flashed stable 21.02.1 from the repository, and everything is OK.
This device has two wifi devices: MediaTek MT7622 802.11bgn and MediaTek MT7915E 802.11nacax I am running the second 5ghz deice in ac mode - setting to ax causes randomly, after some reboots, a dysfunctional 5ghz showing bg (or something similar). Meanwhile, you get decent ax wifi speed, but it does break after some time/reboots.

I am looking forward that a future firmware release does fix the ax issue.
PS: Afterwards I did convert more of them to OpenWrt.

bmork · February 7, 2022, 2:21pm

You mean that the standard UniFi recovery method fails after installing OpenWrt? I.e. this doesn't work?:

If so, then that's unexpected and something which should go into the device page. I tend to think of that as a safety net of infinite strength

knacky · February 7, 2022, 4:12pm

Have you tried downgrading the u-boot version on the U6-LR to the oldest firmware version available from UI's site using fwupdate.real -m

antoninchadima · February 8, 2022, 7:38pm

After flashing OpenWrt, the TFTP was not working on every Unifi 6 LR I had in my hands. I did not open the Unifi to access the serial port to read the messages on the terminal. So I don't know what was wrong. The device did the right LED flashing pattern in upgrade mode, but the TFTP flashing process did not finish correctly. (I have used different TFTP clients, and I have no problem with TFTP with the original firmware).

Downgrading the u-boot is a good idea.

anon69880279 · February 8, 2022, 7:52pm

Same problem with master 21.02.1 & mt7621 + WIFI AX , also 7915E

first WIFI is 2.4 GHz but scan 5GHz band , second WIFI is 5 GHz but " only bg " & scan nothing !!!

solved with snapshot or x-wrt

test with snapshot: https://downloads.openwrt.org/snapshots/targets/mediatek/mt7622/

bmork · February 9, 2022, 7:31am

Makes me wonder if the TFTP recovery works at all on the 6 LR, even without OpenWrt? Unless I miss something, we don't actually change anything outside the bs, kernel0 and kernel1 partitions? These changes cannot break a working recovery. If recovery depends on some special data in any of those partitions then it's not much of a recovery....

I understand the reluctance wrt serial console. I don't open any of these Unifi dishes either if I can avoid it.

netnut · February 11, 2022, 11:52pm

The TFTP thing is rather interesting...

Just sold my 'old' AC-PRO's and bought some U6-LR's to go 'AX'. Got the first one a few days ago and flashed it with the current mt7622 snapshot right away. Besides the LED that isn't working (shuts down 4-5 sec, after power on) didn't run into any issues yet, but haven't used wireless that much.

Ok, back to TFTP, got two other units yesterday and did play around a bit with stock firmware and it looks like the 'official' recovery procedure from Ubiquiti is broken by default or disabled "by design", in contrast to their own "official" recovery procedure, as posted by @bmork .

My findings so far:

Unit ships with v5.60.8, no fwupdate.real downgrade possible to anything lower (v5.43.x). Official recovery procedure is NOT working, tftp just times out. First available update is v5.60.9, same story, tftp recovery is NOT working. Update to latest firmware v5.60.23, again tftp recovery is NOT working.

I did notice some ubootmod files in the OpenWRT snapshot download directory, but flashing these to mtd2 without any context is rather adventurous I guess .

If these units need some 'special' treatment, please share. Tested three units and standard Ubiquiti recovery procedure failed on all of them. Probably gonna use these for the next 4-5 years with OpenWRT, so I have no urgent need to use the recovery...

atftp --trace --option "timeout 60" --option "mode octet" --put --local-file firmware.bin 192.168.1.20
Trace mode on.
Option timeout = 60
Option mode = octet
sent WRQ <file: firmware.bin, mode: octet <timeout: 60>>
timeout: retrying...
sent WRQ <file: firmware.bin, mode: octet <timeout: 60>>
timeout: retrying...
sent WRQ <file: firmware.bin, mode: octet <timeout: 60>>
timeout: retrying...
sent WRQ <file: firmware.bin, mode: octet <timeout: 60>>
timeout: retrying...
sent WRQ <file: firmware.bin, mode: octet <timeout: 60>>
timeout: retrying...
sent WRQ <file: firmware.bin, mode: octet <timeout: 60>>
timeout: retrying...

defa · February 12, 2022, 6:40am

I have been able to recover my u6lr via tftp multiple times. But first a little context: I tried to use the u6lr with the official software, which resulted in an update of the firmware (Not sure which version).

On the first time entering tftp-mode the ap got itself a diffent ip (192.168.1.32). In all later tries it was 192.168.1.20 (like described in the docs).

I had some trouble using different tftp-clients (Windows) but TFTPd64 seems to work.

I have configure a network card as follows:
IP: 192.168.1.22
Subnet: 255.255.255.0
Gateway: 192.168.1.20 (IP of the ap)

You also should wait a moment before trying to start the flashing process.

Hope that helps. I cannot provide more information at is seems that I bricked my device by flashing a 5.43.x version to the device using this method.

netnut · February 15, 2022, 3:56am

I'm talking about factory ubiquiti firmware, that's the point... If the recovery procedure with original firmware isn't working (as described by the vendor itself), well, it's definitely not gonna work after flashing OpenWRT firmware . So far that's my experience with 3 brand new U6-LR's and 3 different factory firmware versions (shipped v5.60.8, upgraded v5.60.9 and latest v5.60.23).

Flashing the standard OpenWRT image shouldn't mess with the uboot partition, ie the recovery stuff. If the 'default' recovery isn't working, you wouldn't be able to go back from OpenWRT to Ubiquiti (at least not without opening the case and do some serial magic). Something that helped me selling my "old" AC-Pro's for a decent price.

So I'm still confused about how and with which firmware versions you did the recovery procedures. Same goes for the IP addresses, the recovery procedure doesn't use DHCP but does use a static IP, which should be 192.168.1.20.

Anyway, at least two U6-LR's are running like champs in ax mode with recent snapshot images, so it's probably gonna take another 4/5 years before I've to think about going back to stock

fpx · February 16, 2022, 6:59am

I also started with a stock 5.60.8. Put it in tftp mode by pressing reset while connecting the device, keep pressing reset until it starts flashing white-blue-off a few times (follow https://help.ui.com/hc/en-us/articles/204910124-UniFi-TFTP-Recovery-for-Bricked-Access-Points).

Network settings:
ip: 192.168.1.25
netmask: 255.255.255.0
(no gateway)

Discover the ip of U6-LR in tftp mode:

$ sudo nmap -sn 192.168.1.*
Starting Nmap 7.91 ( https://nmap.org ) at 2022-02-16 07:14 CET
Nmap scan report for 192.168.1.34
Host is up (0.00011s latency).
MAC Address: D0:21:XX:XX:XX:XX (Ubiquiti Networks)
Nmap scan report for fedora (192.168.1.25)
Host is up.
Nmap done: 256 IP addresses (2 hosts up) scanned in 15.09 seconds

Use the discovered ip to flash a new firmware with tftp (mine was - strange enough - 192.168.1.34):

$ tftp -v
(to) 192.168.1.34
Connected to 192.168.1.34 (192.168.1.34), port 69
tftp> binary
mode set to octet
tftp> rexmt 1
tftp> timeout 60
tftp> put BZ.MT7622_5.60.23+13051.211209.2348.bin
putting BZ.MT7622_5.60.23+13051.211209.2348.bin to 192.168.1.34:BZ.MT7622_5.60.23+13051.211209.2348.bin [octet]
Sent 14649771 bytes in 1.7 seconds [70975982 bit/s]

Success!

bmork · February 16, 2022, 7:20am

Thanks. Looks like there is a bug in the tftp recovery implementation of this device causing it to use an arbitrary ip address instead of the documented one. The documented lack of icmp echo support makes this problem worse, since ping scans won't work.

Your nmap trick should probably go into the device page.

There are now multiple reports that tftp recovery works, but with buggy address selection. Those who couldn't make it work probably didn't find the correct address.

netnut · February 16, 2022, 12:47pm

Right! I can confirm there's a random number generator in the ubiquiti recovery code

My test unit, factory default (v5.60.9), is at 192.168.1.31, recovery succesfull!

bmork · March 7, 2022, 11:47am

Started wondering if this is so random after all. Is it possible that U-Boot simply pulls the address from its config?

I noticed in the log at https://github.com/rickmark/ubnt_u_boot_malware/blob/main/evil_u_boot_ap.txt that the same issue probably is present in the Unifi 6 Lite U-Boot too. I have two of these, but I don't think I've ever tested the TFTP recovery. But I do note that they have this in their U-Boot config:

root@u6-1:~# fw_printenv ipaddr serverip
ipaddr=192.168.1.33
serverip=192.168.1.19
root@u6-2:~# fw_printenv ipaddr serverip
ipaddr=192.168.1.31
serverip=192.168.1.19

Looking at the backups I made before installing OpenWrt, they've had those addresses there since they were new.

My two Unifi AP AC Pro (where I know I have tried TFTP recovery) show the expected address:

root@unifiac:~# fw_printenv ipaddr serverip
ipaddr=192.168.1.20
serverip=192.168.1.254
root@unifiac2:~# fw_printenv ipaddr serverip
ipaddr=192.168.1.20
serverip=192.168.1.254

So maybe all this just is as expected? You just need to make a note of your specific recovery address.

Or maybe the configuration is rewritten by the bootloader under certain conditions? When you use TFTP recovery for example? That would make sense. And could explain the address changes reported in this thread, since they seem to be related to successful TFTP recovery sessions.

knacky · March 8, 2022, 4:40am

Is anyone having a huge performance disparity on 5Ghz with todays (March 7) snapshot or compiling from master?

Down: 7Mbps
Up: 600Mbps

walterav · April 11, 2022, 5:45pm

It might be insightfull to post the leading parts of the MAC address that are printed on the devices/packaging including time/region of purchase.

In the old NanoStation days small hardware revision changes could be detected by different MAC address series, bigger changes by other labeling hints like XM,XW.

opoplawski · October 19, 2022, 9:12pm

I'm having trouble with TFTP timeouts trying to recover the device:

$ tftp
(to) 192.168.1.32
tftp> binary
tftp> rexmt 1
tftp> timeout 60
tftp> put BZ.MT7622_6.0.21+13673.220607.2004.bin
Transfer timed out.

When trying to flash the device initially with OpenWRT it hung while writing the kernel1 image.

Watching the tftp traffic I only see acks for block 0:

  334 461.148988340 192.168.1.32 → 192.168.1.254 TFTP 60 Acknowledgement, Block: 0