Adding support for Ubiquiti UniFi 6 Plus (U6+)

For Developers
62

I took the liberty to put together what I believe we have now, included all your work I've picked up in this thread. You'll find it here: https://github.com/bmork/openwrt/tree/u6plus-dev

Could you look over that, correct stuff, and add signed-off-by and authorship as you see fit?

My claim is that this is as ready as it will be. Anything remaining, like bluetooth support, can be added later. If anyone cares.

FYI: I did a few test installs and found that the "devmode" setting isn't actually needed. Could you confirm that?

I also decided that the separate kernel+rootfs images are unnecessary since we want a simple tar sysupgrade anyway. This is easily unpacked on the target stock firmware. Less images is less confusing.

Note that the wifi mac-address setting depends on https://github.com/openwrt/mt76/pull/817 (or some other fix), or you'll get the same address on both phys.

I believe I've tested most of this:

  • ram boot
  • install from stock running kernel0
  • install from stock running kernel1
  • sysupgrade

but more testing by more people would certainly be good.

Personally, I'm ready to screw t this on the wall now :slight_smile:

63

Looks good to me, it's essentially what I have. My repo has your MT76 driver fix though, I presume these should be separate pull requests? I need to take a closer look at WiFi MAC address assignment (such as the 11-fix-wifi-mac script) but honestly none of that prevents "real world tests" from commencing.

In the meantime I will test the "stock-to-OpenWrt" procedure I have written for the wiki again. I will report if devmode = TRUE is needed. After that I'll add my signed-of-by to the commit. I can submit the pull request, if you don't mind.

Question regarding the 11-fix-wifi-mac script: I see it sets MAC addresses for each PHY in the device. What does OpenWrt do if I create additional SSIDs? Is there another script or does it simply increment the address?

64

That's my understanding as well. Mixing too much into a device addition pull request makes the process more complicated than necessary in my experience.

Sounds like a great plan to me!

Yes. This is a generic problem for all devices and it has a generic solution. The addresses are auomatically generated by the hostapd package AFAIK.

Thinking of this - maybe it isn't a big problem that the phys use the same address as long as all the generated BSSIDs are unique? No need to hold off device support for the answer. The DTS is as correct as we can make it anyway. If duplicate addresses are fine, then we'll just get that as feedback to the mt76 PR.

Hmm, I see that I have ignored that script while most other devices use it to work around the lack of driver support. That feels wrong to me, but maybe I'm the one being wrong here?

But we do have the base mac-availabe in the device tree. Why shouldn't the driver use it directly?

65

I can confirm that devmode TRUE is not needed, only these bootloader variables are needed:

fw_setenv boot_openwrt "fdt addr \$(fdtcontroladdr); fdt rm /signature; bootubnt"
fw_setenv bootcmd_real "run boot_openwrt"

I've also done the TFTP stock recovery and device flashing procedure a few times now, so it appears the instructions I've written down does work. I'll put it up on the wiki after I get wiki access.

For the Wifi MAC addresses I've modified 11_fix_wifi_mac:

diff --git a/target/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac b/target/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac
index ea85939068..0fc90bd41b 100644
--- a/target/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac
+++ b/target/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac
@@ -58,6 +58,11 @@ case "$board" in
                [ "$PHYNBR" = "0" ] && macaddr_add $hw_mac_addr 2 > /sys${DEVPATH}/macaddress
                [ "$PHYNBR" = "1" ] && macaddr_add $hw_mac_addr 3 > /sys${DEVPATH}/macaddress
                ;;
+       ubnt,unifi-6-plus)
+               addr=$(mtd_get_mac_binary EEPROM 0x6)
+               [ "$PHYNBR" = "0" ] && echo "$addr" > /sys${DEVPATH}/macaddress
+               [ "$PHYNBR" = "1" ] && macaddr_add $addr 1 > /sys${DEVPATH}/macaddress
+               ;;
        qihoo,360t7)
                addr=$(mtd_get_mac_ascii factory lanMac)
                [ "$PHYNBR" = "0" ] && macaddr_add $addr 2 > /sys${DEVPATH}/macaddres

This ensures the two radios get different MAC addresses, derived from the factory EEPROM.

I'm now running OpenWrt on U6+. I've configured a DHCP and DHCPv6 client on the AP so it gets IP addresses from the upstream router. I've also configured the wireless networks on both radios as I usually do.

Currently, I have a few clients connected to the AP. One of those devices supports WiFi 6 (via Intel AX200), nevertheless all clients have full connectivity. So far, everything looks good. I'll daily drive this setup for a week and see how it goes. If there's no problems, expect a pull request sooner than later. :+1:

1 Like
66

Fork: github.com/ElbertMai/openwrt/tree/ubnt-unifi-6-plus
Pull request: github.com/openwrt/openwrt/pull/13472

U6+ support has been merged into OpenWrt!

Snapshot images built daily can be found on the firmware selector. Despite what it says on the selector page, you want the sysupgrade image even if you're flashing from stock firmware.

You can also build OpenWrt for U6+ by cloning the official repo and following the build system instrctions on the wiki.

In either case, installation instructions are in the commit message. Pay attention to the partition names! In particular, do not touch any partition named "factory". This stores factory data needed for the radios to work.

Major thanks to @bmork for help with bringing OpenWrt to yet another device :beers:

3 Likes