Ubiquiti M5 Firmware
Kanisha Dezarn
In my particular case this question relates the UniFi AP v2 but has more general implications.
One would imagine this to be a simple question to answer with a yes or no answer but not for Ubiquiti it seems.
I have been asking this question of Ubiquiti for about a month now after having problems loading OpenWRT 15.05.1 into a number of UniFi AP v2 units. The answers from Level 1 support (via their forums) has been, "It shouldn't be blocked" (hoping for a Yes or No), "It's ok in the latest release" (it wasn't), "I'll have to check with Development" (still waiting for that), "We don't support Third Party Firmware" (wasn't asking for support) or (the most honest) "I don't know". So I pressed for an answer, they escalated it to the next level but were very vague about what that meant. Oh and it seems Level 1 support at Ubiquiti have no SLA what so ever with the team they escalate to. They also have no way to communicate with them after an escalation. So the question has gone some where in Ubiquiti to be answered at some unknown time.
My own feeling is that they are avoiding answering the question as they took the excuse of the FCC rules relating to unauthorised changes to Wireless parameters that could be part of Third Party Firmware, to do this. Of course the FCC rules only applied to 5Ghz not 2.4Ghz Wireless and, as the FCC have stated, was not intended to be used as a reason for blocking Third Party Firmware. TP-Link got caught up in this too. So they cant say they are blocking.
I also think they are actively blocking. Firmware Images for the UniFi AP v2 have a different device type in their header but this is easy to cater for by either making changes in the OpenWRT firmware builder to generate a correct header (sorry not going to go into derail on that here) or by using a binary editor to change it manually. The real issue is that the Ubiquiti Firmware images have a new RSA signature section at the end. The U-Boot loader, already on the device and included in Ubiquiti Firmware updates, checks the signature and rejects images that don't have it, making TFTP updates not work. fwupdate.real used to do upgrades via the command line, also checks and rejects images without the signature giving the "Invalid FW Part 3 MAGIC 'END.'" message.
I'm interested to hear other peoples thoughts on this please.
Hello. Did you get OpenWRT or LEDE working on the UAPv2? I need to use this third party OS to make the device act as router, firewall and multi-AP, and with these new versions I can't. This is the worst thing Ubiquiti could do to these devices...
No. It's not really a matter of getting OpenWRT or LEDE to work, it's about Ubiquiti blocking the installation of third party firmware in the first place by checking that any firmware has the correct RSA signature before its even loaded. Ubiquiti wont even discuss this. Try asking the question on their support forum and see what they say .
One thing is support the 3rd party firmware and another, completely different, is not allowing me to install it at the ubiquiti devices. Are you telling me that Ubiquiti is restricting the 3rd party firmwares installation?
i've recently came up with an idea how to flash locked/signed firmware on litebeam ac gen2. basically you start flashing same ubiquiti fw that is already on device and interrupt the process, that leaves mtd partitions unlocked and you can flash another image to these using dd. more info in this GH comment-> -493658317
I updated the Ubiquiti controller software today as I noticed there was a recent update. After updating the controller software, I also noticed that there was a firmware update for my UAP-AC Pro access point. I updated to the latest firmware version which is 6.6.65.
During the afternoon, the internet dropped out at least once an hour - or more specifically the wireless dropped out. When trying to upload the older firmware to my website using filezilla, I noticed the connection in filezilla kept erroring out. So I had to connect via cable to upload the older firmware in order to restore my ap to the older version.
According to this, -Access-Point-6-6-65/3df9b0c0-7e51-4843-93a2-276c2d63e10a?page=1, a lot of people are having issues with this firmware version. The next release which is still in beta testing seems to have fixed the issues. I will just wait until the next release is production ready and upgrade to that bypassing version 6.6.65. The older version works perfectly, so I see no pressing need to upgrade.
I have just updated to the very latest firmware 6.6.73. According to the release notes they have fixed the problems present in 6.6.65. I will update tomorrow if this release is safe to update for ac-uap pro access points which are only using 5.2ghz.
Barrier Breaker 14.07 openwrt-ar71xx-generic-ubnt-unifi-squashfs-factory.bin works out of the box, no need to change XM/BZ for the firmware image. Configurations then can be changed right away using LuCi.
Later 3.xx firmware versions fail to upgrade using the above and brick so use instead. If brick reset device with 20-sec-press way with connected lan-cable - after it tftp start work.
Important: the last number in that line (0x400004) refers to the size from the last line of TFTP transfer (400004 hex). Other OpenWrt firmware files can have other sizes. Mind to adjust command line as needed. The size should be 0x52012f for 21.02.1reply:
If you have already installed OpenWrt and like to reflash for e.g. upgrading to a new OpenWrt version you can upgrade using the sysupgrade command line tool. It is important that you put the firmware image into the ramdisk (/tmp) before you start flashing.
How to connect to JTAG interface, and how to reflash the device with JTAG tools
See port.jtag for more JTAG details.
The USBJTAG NT also supports read, write, erase, debrick, etc. You can use the WRT160NL config, or download the specific device config from this forum post.
This is a working standalone router setup, working as of 17.01.4.The old version used a trick with bridging a nonexistent interface (eth1) for no real reason, and it didn't work for me. Instead, I just set the wlan0 interface to be the lan network and everything worked perfectly. This is a working configuration that should be default, in easily pasteable form:
The UniFi has only the single ethernet port, so much of the OpenWrt documentation is a little confusing. Most of the documentation is written with the idea of routers which have a WAN port, a LAN wired switch and the WLAN wireless. Clearly the Unifi doesn't have the wired LAN switch.
After flashing (I found r41163 worked while the 12.09 version had the XM problem discussed above and editing the characters 4-6 didn't fix it) I was able to connect via wired ethernet as described in FirstLogin (i.e. there is a DHCP server handing out IPs in the 192.168.1.X subnet, running on the ethernet port).
After changing the password and exiting, I had to wait a while (60 secs?) until I could ssh back into the box. That was strange because I thought I'd lost networking ... I think that is due to a long-running first time ssh key generation. Even so, each ssh in takes a long time to respond (something about recent versions of dropbear taking a long time to setup a session key). I found LUCI not installed, so I had to work to get internet access on the box before I could use that.
Once ssh'd into the box I followed these steps: 1. Enable wireless, using commands at top of the UCI wireless config page. This enables the radio. The radio is bridged to the lan network.2. Connect to the wireless network, disconnect the wired from your computer, and ensure that you can ssh in via the wifi.3. Swap eth0 and eth1 between lan and wan. The default configuration has the ethernet port on the lan network. But if you are going to plug the Unifi into a cable modem (for example) to use it as a router, then you want the ethernet port to be the wan network (and to seek a dhcp assigned address). I edited the /etc/config/wireless file changing etho in the lan section to eth1, and eth0 in the wan section to eth1. Quite honestly I'm not sure that this is perfect (since there isn't an eth1 on the Unifi, but it worked for me).4. Restart networking (/etc/inid.d/networking restart)5. Connect the ethernet lan on the PoE injector to the cable modem. Remember nonsense about having cable modem off for 20 seconds or so to give out an IP to a new MAC address.6. Connect back to the OpenWrt Wifi.7. ping google.com. yay.
In a situation where you'd just like to drop the AP in an existing network, it might be handy to use DHCP. However, how do you figure which IP the AP is using... Below config allows you to use a DHCP assigned IP and still keep an extra IP address (192.168.254.1) you can use to directly connect over the ethernet port.
Your usual 'ifconfig -a' will not show this 2nd IP. Yes, this very confusing and is caused due to a limitation of Busybox. You'll have to use the 'ip' command which you can install using 'opkg install ip'.
e59dfda104