OpenWRT on Ubiquiti AC Lite

Posted on 2016-May-30 in programming

Ubiquiti Unifi AC-lite

A year ago, I thought I had upgraded my home WiFi to AC with the purchase of a cheap TP-Link Archer C5, but it only gave me trouble. The 2.4GHz band is working perfectly, the 5GHz not so. The first version of OpenWRT I installed had no support at all for the 5GHz mode, I had to dig out from the openwrt mailing-lists that something was under way to add support for it, find the right rxxxx release, compile it myself and install it, only to be disappointed. In the end I got it almost working: network would drop every minute or so, and the range would not exceed a few meters away from the access point. Quite worthless.

Ars Technica reported last year about switching from consumer-grade WiFi access points to professional ones here:

Ars Technica review of Ubiquiti Access Points

Took me a while to finally give up on the Archer C5 and decided to get the cheapest Access Point from Ubiquiti: the Unifi AC Lite unit.

Several things play in favour of this access point: it is designed to be hanging on a wall or a ceiling for a better wave spread, offers much higher power than your usual consumer-grade WiFi device, and the firmware is in the hands of Ubiquiti so they are taking care of making sure the unit is performing as it should. Or so I thought.

First surprise: the device cannot be started out of the box. You need to download the Unifi Controller software, a 200MB piece of java software that is meant to control the unit. Install the Controller on any computer on your local network, start it up, let it discover your access point, and you are good to go. The Controller starts up a local web-based interface which is accessed via a local web browser.

Ubiquiti designed it this way because this product is not meant to be purchased as a single unit but in batches and installed in hotels or offices. The Controller software has obviously been designed to maintain a long list of such access points. Having just one looks a bit ridiculous but Ok, I'll play along.
To be fair: if you do not want to install the Controller locally you can also run it from an internet box (look Ma, it's the cloud!). For companies or hotels who do not have servers on site it is an excellent idea but for a single AP this is largely overkill. I am not keeping a java server up full time on the Internet to manage an Access Point in my living-room. And if you do not want to run the Controller at all, you can also just start it whenever you need to modify your AP configuration and shut it down afterwards, which is what I did.
I mounted my AP on a top shelf, ran the initial configuration, and was delighted to see a double-band WiFi emerge immediately. Strong signal everywhere in the house, no connection issues, great! A welcome enhancement to my home network.

The only notable modification I brought was to stick a white Apple sticker on the Ubiquiti logo to hide it. The point was not to rebrand it as an Apple product but to hide this ugly U and this was the only sticker I had available that day. The Ubiquiti guys are probably not aware that they have the very same logo as a cheap French supermarket brand and I got tired of seeing that prominently displayed in my living-room.

After about a month, a few things started bothering me though. The AP seemed to have trouble waking up after losing power. First boot would report everything fine but WiFi would drop every connection immediately.  Rebooting the AP solved it every time. Did not feel too good about this.

Nmap'ing the unit revealed an open ssh port, which accepted the admin credentials that were set on the controller software. Once logged in, I found myself in front of some kind of heavily modified OpenWRT. Interesting... So is there anything on the Ubiquiti web site about this modified OpenWRT? After all, OpenWRT is under GNU license (v2) so I expected to find sources, some kind of build system, or anything related to the modified OpenWRT version running on my Access Point, but I could not find anything, at least nothing obvious from the Ubiquiti web site. Bad point for Ubiquiti but I am not a lawyer.

Nosing around the logs for some explanation for the needed reboots, I found nothing obvious. What I found was that a process was spitting a few lines every five seconds about having no contact with the Ubiquiti Controller software. Several questions on the Ubiquiti forums on that topic were answered with: "yes we know, this is a low-priority fix, just ignore it for the moment". I have to say that just pushed me over the edge. I understand that my case is not the general use case and I truly do not blame Ubiquiti, but this is not the way I want my AP to work. I do not care much about log files filling up with useless messages but the lack of interest for single-AP users like me is disturbing.

So off to installing a real OpenWRT firmware this time. I finally got it working but it took me a whole afternoon of research to do so, which is summarized here in case it can be useful to somebody else.

First: the current (3.7) firmware embeds an RSA signature check preventing any attempt to install non-Ubiquiti firmware. This is probably due to the recent FCC firmware lockup rules. While I do understand the FCC concerns and the important role they play in Homeland Security, I regretfully do not feel obliged to follow US rules on European ground. This is my hardware now, if I decide to mess it up with another firmware I should be able to do so.

Solution: downgrade the firmware to version 3.4, which is signed by Ubiquiti and does not check firmware update signatures. This firmware can be found by googling a bit around, I got a working URL and the complete procedure from this page:

LEDE/OpenWRT for Ubiquiti UniFi AP AC (LITE + LR + PRO)

While we're at it, it may be a good idea to switch from OpenWRT in favour of the recent project fork called LEDE project. Seems they have added official support for this hardware and the documentation seems a lot cleaner, though very, very incomplete for the moment, which is perfectly Ok for a two-week old project.

If you did not follow what happened to the OpenWRT project recently, you may be interested in learning a bit more about why the team forked:

Some pre-built images are available from the LEDE project site, but I chose to go all the way and clone the github repository, configure the build to include the software I need, and recompile everything myself. On a beefy x64 server this took about 2 hours and 11GB of disk space, ending up with a 3.3MB image that was happily installed in a single command on the downgraded Access Point.

The default configuration is smart: the AP tries to obtain an address for itself through DHCP on its only wired interface and acts as a bridge for wireless clients, making it immediately operational when connected to a network equipped with a proper DHCP server. Sweet.

Net result: my Unifi AC AP is now completely stand-alone. I happily removed the Ubiquiti Controller software and customized my AP to death with various scheduling and logging scripts. Wireless range in the 5GHz band covers the whole house and the 2.4GHz allows me to walk outside during Skype calls without losing signal. No more spontaneous rebooting, my logs are clean, and most importantly: I feel empowered :-)

I have to say I do not see Open-source firmware disappearing any time soon.  For tinkerers like me who like to have complete control over their network, this is absolutely brilliant.

Edit: 2016-12-09 Adding some config files and diagnostics to this page, might be helpful if you are trying to replicate this

/etc/config/wireless defines two access points: ap24 for 2.4GHz and ap50 for 5GHz, with passwords SECRETPASSWORD.

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path 'platform/qca956x_wmac'
    option txpower '20'
    option country 'FR'
    option distance '50'
    option channel '3'

config wifi-iface
    option device 'radio0'
    option network 'lan'
    option mode 'ap'
    option ssid 'ap24'
    option encryption 'psk2+tkip+ccmp'
    option macfilter 'deny'
    option key 'SECRETPASSWORD'

config wifi-device 'radio1'
    option type 'mac80211'
    option hwmode '11a'
    option path 'pci0000:00/0000:00:00.0'
    option htmode 'VHT80'
    option txpower '20'
    option country 'FR'
    option distance '50'
    option channel '136'

config wifi-iface
    option device 'radio1'
    option network 'lan'
    option mode 'ap'
    option ssid 'ap50'
    option encryption 'psk2+tkip+ccmp'
    option key 'SECRETPASSWORD'

Here are the outputs of iw phy0 info:

#iw phy0 info
Wiphy phy0
 max # scan SSIDs: 16
 max scan IEs length: 199 bytes
 max # sched scan SSIDs: 0
 max # match sets: 0
 Retry short limit: 7
 Retry long limit: 4
 Coverage class: 0 (up to 0m)
 Device supports AP-side u-APSD.
 Available Antennas: TX 0x3 RX 0x3
 Configured Antennas: TX 0x3 RX 0x3
 Supported interface modes:
 * managed
 * AP
 * AP/VLAN
 * monitor
 * mesh point
 Band 2:
 Capabilities: 0x19ef
 RX LDPC
 HT20/HT40
 SM Power Save disabled
 RX HT20 SGI
 RX HT40 SGI
 TX STBC
 RX STBC 1-stream
 Max AMSDU length: 7935 bytes
 DSSS/CCK HT40
 Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
 Minimum RX AMPDU time spacing: 8 usec (0x06)
 HT TX/RX MCS rate indexes supported: 0-15
 VHT Capabilities (0x338001b2):
 Max MPDU length: 11454
 Supported Channel Width: neither 160 nor 80+80
 RX LDPC
 short GI (80 MHz)
 TX STBC
 RX antenna pattern consistency
 TX antenna pattern consistency
 VHT RX MCS set:
 1 streams: MCS 0-9
 2 streams: MCS 0-9
 3 streams: not supported
 4 streams: not supported
 5 streams: not supported
 6 streams: not supported
 7 streams: not supported
 8 streams: not supported
 VHT RX highest supported: 0 Mbps
 VHT TX MCS set:
 1 streams: MCS 0-9
 2 streams: MCS 0-9
 3 streams: not supported
 4 streams: not supported
 5 streams: not supported
 6 streams: not supported
 7 streams: not supported
 8 streams: not supported
 VHT TX highest supported: 0 Mbps
 Frequencies:
 * 5180 MHz [36] (20.0 dBm)
 * 5200 MHz [40] (20.0 dBm)
 * 5220 MHz [44] (20.0 dBm)
 * 5240 MHz [48] (20.0 dBm)
 * 5260 MHz [52] (20.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5280 MHz [56] (20.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5300 MHz [60] (20.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5320 MHz [64] (20.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5500 MHz [100] (27.0 dBm) (radar detection)
   DFS state: available (for 2032379 sec)
   DFS CAC time: 60000 ms
 * 5520 MHz [104] (27.0 dBm) (radar detection)
   DFS state: available (for 2032379 sec)
   DFS CAC time: 60000 ms
 * 5540 MHz [108] (27.0 dBm) (radar detection)
   DFS state: available (for 2032379 sec)
   DFS CAC time: 60000 ms
 * 5560 MHz [112] (27.0 dBm) (radar detection)
   DFS state: available (for 2032379 sec)
   DFS CAC time: 60000 ms
 * 5580 MHz [116] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5600 MHz [120] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5620 MHz [124] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5640 MHz [128] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5660 MHz [132] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5680 MHz [136] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5700 MHz [140] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5720 MHz [144] (disabled)
 * 5745 MHz [149] (disabled)
 * 5765 MHz [153] (disabled)
 * 5785 MHz [157] (disabled)
 * 5805 MHz [161] (disabled)
 * 5825 MHz [165] (disabled)
 valid interface combinations:
 * #{ AP, mesh point } <= 8, #{ managed } <= 1,
   total <= 8, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
 HT Capability overrides
 * MCS: ff ff ff ff ff ff ff ff ff ff
 * maximum A-MSDU length
 * supported channel width
 * short GI for 40 MHz
 * max A-MPDU length exponent
 * min MPDU start spacing
 Device supports VHT-IBSS.

Here are the ouputs of iw phy1 info:

# iw phy1 info
Wiphy phy1
 max # scan SSIDs: 4
 max scan IEs length: 2257 bytes
 max # sched scan SSIDs: 0
 max # match sets: 0
 Retry short limit: 7
 Retry long limit: 4
 Coverage class: 1 (up to 450m)
 Device supports AP-side u-APS.
 Device supports T-DLS.
 Available Antennas: TX 0x3 RX 0x3
 Configured Antennas: TX 0x3 RX 0x3
 Supported interface modes:
 * IBSS
 * managed
 * AP
 * AP/VLAN
 * WDS
 * monitor
 * mesh point
 * P2P-client
 * P2P-GO
 * outside context of a BSS
 Band 1:
 Capabilities: 0x11ee
 HT20/HT40
 SM Power Save disabled
 RX HT20 SGI
 RX HT40 SGI
 TX STBC
 RX STBC 1-stream
 Max AMSDU length: 3839 bytes
 DSSS/CCK HT40
 Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
 Minimum RX AMPDU time spacing: 8 usec (0x06)
 HT TX/RX MCS rate indexes supported: 0-15
 Frequencies:
 * 2412 MHz [1] (20.0 dBm)
 * 2417 MHz [2] (20.0 dBm)
 * 2422 MHz [3] (20.0 dBm)
 * 2427 MHz [4] (20.0 dBm)
 * 2432 MHz [5] (20.0 dBm)
 * 2437 MHz [6] (20.0 dBm)
 * 2442 MHz [7] (20.0 dBm)
 * 2447 MHz [8] (20.0 dBm)
 * 2452 MHz [9] (20.0 dBm)
 * 2457 MHz [10] (20.0 dBm)
 * 2462 MHz [11] (20.0 dBm)
 * 2467 MHz [12] (20.0 dBm)
 * 2472 MHz [13] (20.0 dBm)
 * 2484 MHz [14] (disabled)
 valid interface combinations:
 * #{ managed } <= 2048, #{ AP, mesh point } <= 8, #{ P2P-client, P2P-GO } <= 1, #{ IBSS } <= 1,
   total <= 2048, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz }
 * #{ WDS } <= 2048,
   total <= 2048, #channels <= 1, STA/AP BI must match
 HT Capability overrides:
 * MCS: ff ff ff ff ff ff ff ff ff ff
 * maximum A-MSDU length
 * supported channel width
 * short GI for 40 MHz
 * max A-MPDU length exponent
 * min MPDU start spacing

Have fun with your new Access Point!