Ubiquity 6 LR upgrade to snapshots not working

Hi,
I have several OpenWRT routers running, I now wanted to use some UniFi 6 LR with OpenWRT for fast 802.11ax + 802.11r.
unfortunately the stable build has issues with WiFi (on other forum topics), so I tried to flash directly the latest snapshot (in Luci, not keeping settings)
This instantly breaks the router; it's not booting anymore. I have to unbrick using TFTP (unfortunately sometimes with undocumented address 192.168.1.34).

Is there some idea besides waiting for the next stable relaese?

Regards,
Florian

Using what file, going from which version?

Remember that snapshot builds do not have Luci, you will need to log in with ssh.

1 Like

openwrt-21.02.3-mediatek-mt7622-ubnt_unifi-6-lr-squashfs-sysupgrade is working initially.
openwrt-mediatek-mt7622-ubnt_unifi-6-lr-squashfs-sysupgrade is used for update. I tried the snapshot from 03.06. and 10.06.

I forgot the missing Luci, but the device is not even responding to pings.

I had a similar experience on Unifi 6 Lite about a week ago. It appeared stone dead after an upgrade to commit 4e1916f71aec ("mt76: update to the latest version"). Never got the chance to look more into it. I needed the access point, and I'm still hoping to avoid breaking it open to get console. Was wondering if that mt76 commit could be the problem? It seemed like the most likely candidate. But I also made a few config changes, including moving to GCC 12, so there are plenty of other candidates too.

But that driver is probably the only thing in common between the 6 LR and the 6 Lite, which is why I am mentioning this now. Maybe it's related to your problem?

FWIW, I went back to the previous image I built, based on commit 90e4c8c6e6fe ("bmips: dgnd3700v2: fix network config"), after the mandatory tftp rescue.

First time I had to do that. Finally confirmed the theory that the rescue IP address is what's stored in the U-Boot environment variable "ipaddr" and not necessarily 192.168.1.20 as documented. Interestingly, this variable was reset to 192.168.1.20 after rescue. Makes me wonder if these odd addresses are leftovers from some factory testing and only an issue on the very first tftp rescue?

1 Like

Red herring. I built an image from current master now, making fewer changes and doing a proper "make dirclean" first. And it worked just fine, like OpenWrt usually do as long as I just follow the recommended procedures.

Sorry for the noise in this thread. Looks like my issue was self inflicted.

I did some more testing...
it appears that the upgrade is in fact working. But the bridging or eth0 interface is broken afterwards. If I configured WLAN interfaces before I still can connect and configure. But the device is not reacting on eth0.

I tried to configure a new eth0 based bridge interface. The router is counting outgoing packets (no incoming) on this bridge interface, but I don't see any packet on my laptop in the capture. Log is showing that the device eth0 is up, but it's acting like it's down.

I have no idea now; any idea here?
I only have this 100MBit/s PoE Switch here, so direct connection or GBit Switch is not testable at the moment.

tested with another switch - it's working!
So the issue is something in the ethernet / LAN after the last release, but only with this unmanged Netgear ProSafe FS108P.

Had the same problem; it ewas a faulty cable. Weird it worked with the initial firmware but not with the trunk.