hey there.
I just recently flashed 2 of my UniFi UAP (accesspoints). Originally there was the UniFi Firmware 4.0*** on it, so I had to go the way via serial connection. Worked on 2 of 3, but not really on the third. So it bricked and was not really recoverable for some time.
After several attempts I got the openWRT flashed on the device. I logged into openWRT flawlessly. But after the first reboot the device remained in the tftp mode (LED is blinking yellow-green-off). When I reconnect the serial adapter, I am able to interrupt the waiting state of the device in tftp so that it continues to boot. After that, it works fine !
To be honest, I dont want to connect via serial every time I have to reboot the device
As I said before, 2 other devices (also UniFi UAP) could be flashed without any problem...
Any help or hint to point me to the right direction is appreciated...
Thanks
Here is the console output after a normal boot (lan/poe plugged in, reset NOT pressed).
Other than you might expect while reading the following lines : I did NOT press the reset during boot.
The PoE adapter can cause a reset by sending voltage on one of the data pairs (there is a tiny reset button on the bottom). Check that the cat5 cable is not shorted or waterlogged. Try a different PoE adapter.
Thanks for that hint. Checked that with a new/other cable and a different injector. No changes.
I "cross checked" that with the one UAP working. This one boots flawlessly with any of the used
cable and injector combination (I have 3 injectors here and used 2 different 5E cables on the PoE side).
Took some time but imho, the cause for this problem is not the cable nor the injector...
Will investigate further as I will not let the UAP end as brick.
Has had somebody the same behaviour on a UAP or any other device ?
Reboot, monitoring the console. Interrupted the autoboot, checking for the rootfs.
It appears and seems to be ok, but when you take a look at the row :
OpenWrt does not need or use a mtdparts table. The bootloader boots the kernel then the kernel scans the flash to find the rootfs and create the overlayfs.
The problem here is that the booltoader finds the reset GPIO active and goes to TFTP recovery mode as if the reset button were pressed. This is likely a hardware issue. There is a zener diode which detects the voltage on one of the data pairs in the RJ45 then turns on a transistor in parallel with the reset button to cause a remote reset. It could also be simply that the reset button is stuck.
If you just bought this unit new and don't want to do hardware troubleshooting, I'd suggest flash it back to stock and return it for warranty.
As far as I know and understood several discussions about the unifi firmware, the rootfs does not longer apear from version 4.X on. So you can will find several times the hint to downgrade the firmware to a 3.X version as there the rootfs is „there“ and the uploded image does not need to be signed by ubiquiti/unifi.
Sadly, in the meantime, my second of three accesspoint acts the same like the bricked one.
I guess I did not realize this fact before.
And due to this fact, i doubt a hardware problem... perhaps the downgrade killed anything of the bootloader-section-thing ?? hope to recover that in near future.
OpenWrt does not need or use a mtdparts table. The bootloader boots the kernel then the kernel scans the flash to find the rootfs and create the overlayfs.
... with firmware version 4, the rootfs does not longer appear when you enter "mtdparts".
So, from my understanding, I have to create them...
At the moment my focus is on unbricking these two devices. My next step is trying to recover the original stock firmware and start from the beginning. @mk24, do you have a confirmed working instruction for flashing devices > fw 4.X ?
Are you talking about the old model with AR7241 chip? I do have one here I could experiment on.
Label on the back says
bgn WiFi Certified
"UniFi AP LONG RANGE"
M/N: UniFi AP
FCC ID: SWX-UAP
IC:6545A-UAP
hmmm... looks almost identical.
The chip says AR7241 (AR7241-AH1A). Do you think, that our devices are the same but only differently named ?
On the green PCB is printed : UBIQUITI (C) 2010 EN_AP2
yapp, seems to be an older device
I used the latest openWRT at that moment (19.07.6) : openwrt-19.07.6-ar71xx-generic-ubnt-unifi-squashfs-factory.bin
Used a MacBook Pro with native Ubuntu Linux 20.04 and an FTDI232 USB -TTL converter. Used the stock ubiquiti poe injector and CAT 5e lan cable.
I am not sure if this information gives you an advantage at this ? but before you have to ask ....
@Mr.Brick@mk24 I also have one of these with stock firmware 4.3.24.11355. As in less than a month's time they can no longer be adopted by the controller, I'm curious about OpenWrt flashing options. Is there a way to downgrade to pre-3.7 firmware? How are they flashable with serial console access?
My UAP-LR seems to have the 4.3 bootloader already. Bootloader version unifi-v1.6.17.296-g1af7670c is reported. This bootloader seems to accept a TFTP recovery upload of 3.7.58 but it doesn't flash properly and ends up bricked.
Stock firmware version 4.3.24 can be installed with a TFTP recovery flash. This is good to confirm that the hardware is OK. Also you can fwupdate.real 4.3.24 from the stock firmware which will re-flash the bootloader (bootloader is not changed with TFTP recovery). However it is not possible to downgrade to previous stock, or to install OpenWrt, from the 4.3.24 stock shell.
OpenWrt can be installed over 4.3.24 via the bootloader console, manually TFTP booting an initramfs build of OpenWrt then using it to sysupgrade flash a final build. Serial connection and TFTP server is required.
Downgrading the bootloader would probably require extracting the bootloader code from an older version of official firmware and using kmod-mtd-rw and mtd under OpenWrt to directly flash it. This is risky and not necessary to run OpenWrt.
Ok, extracting the bootloader from an older version seems to be a way, I am not able to go with my knowledge at this point Is there any other way to restore my 2 ap's ? I assume, that flashing back to an actual stock firmware (like 4.something) could make my ap's at least useable again ?
In the meantime I remember, that I tried a few methods to flash openwrt on the UAP as there was the method to downgrade to a 3.something version. I guess, that this step lent to success in the end...
I used the method to ping the UAP and at the same time accessing via (Win)scp to the UAP.
To be honest, flashing a device is a great thing as it gives further lifetime to an EOL device... but even when Ubiquiti states this device to be EOL, from the perspective of hardware, it is not (and the one working UAP device states me right)
From my point of view, any company selling products that run into EOL after a period of time should make their devices open to 3rd party firmwares once, they are EOL. Why should I put this device into the trash can and buy a new one ? For sure, from the perspective of a company and all the employees and the goal to earn money... I guess I would pay more for a product where I know, that I can use it till the moment of magic smoke or my decision, not to use it any longer. But I do not like to have this decision taken by anybody else and their aim to make money money money... weird world... but don't get me wrong, that is my 2 or 3 cents, and I also want to earn money from my job...
@stangri I know, there are a lot of instructions out there, how to flash these devices. From my experience, downgrading to 3.something is the only way to success. There is a youtube video that shows to ping the UAP from the commandline (ping 192.168.1.20 -t) and at the same time to access the UAP with WinSCP (connection method SCP on the UAP IP) and PUT the 3.something file onto the UAP. Give it a try. When you are connected with the serial cable, you should see the success of the downgrade on the console. From that point on, you can follow the openwrt instructions...
I appreciate every comment on my question and want to say THANK YOU for your time helping me !!
It is possible to install OpenWrt without downgrading. You will need serial access (which you have) to perform that installation. Once 4.3 has been installed it is not simple to downgrade. The older stock firmware and bootloader allowed installing OpenWrt via a "factory" image-- but other than that there is no need to run the older stock bootloader or firmware. Once OpenWrt is installed you can upgrade OpenWrt by running sysupgrade in the usual way without serial.
First I'd TFTP in 4.3 and boot it up then fwupdate 4.3 again which will re-flash the bootloader (with what should be the same one). From there install OpenWrt using an initramfs.
The going to TFTP even when the reset button is not pressed is very strange. If it keeps doing that you should check the hardware around the reset button. My unit has a place for the transistor I was talking about, but no transistor is installed on the board. So only the button can cause TFTP.
Sorry for my late reply. Will give that a try in the next days. Thank you very much for your help.
This tftp-boot-thing made me almost crazy. Both devices behave identically, so I do not expect a hardware issue at that point...
I hope I do not forget to report any success or frustration here after I invested some more time in my two bricks
I'm also attempting to make use of some UAPs. I've tftp'd an initramfs image to the device, booted from that, then flashed that initramfs to mtd2 and the device boots into the initramfs just fine, but when I attempt to write openwrt-19.07.7-ath79-generic-ubnt_unifi-squashfs-factory.bin to /dev/mtd2, the UAP fails to boot, complaining about "Bad magic Number" -- what is needed to correctly flash the squashfs image?
root@OpenWrt:/# mtd write /tmp/openwrt-19.07.7-ath79-generic-ubnt_unifi-squashfs
-factory.bin /dev/mtd2
Unlocking /dev/mtd2 ...
Writing from /tmp/openwrt-19.07.7-ath79-generic-ubnt_unifi-squashfs-factory.bin to /dev/mtd2 ...
root@OpenWrt:/# reboot
root@OpenWrt:/# [ 767.378400] br-lan: port 1(eth0) entered disabled state
[ 767.396469] device eth0 left promiscuous mode
[ 767.400935] br-lan: port 1(eth0) entered disabled state
[ 767.415352] eth0: link down
[ 767.429237] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 771.705413] reboot: Restarting system
U-Boot unifi-v1.6.17.296-g1af7670c (Apr 22 2019 - 11:05:55)
DRAM: 64 MB
Base:0x80000000, Top:0x84000000, Res logbuf:0xa3ff3800, log_magic:0x9b294cb2 kseg: 0xa0000000
Flash: 8 MB
PCIe WLAN Module found (tries: 1).
Net: eth0, eth1
Board: Copyright Ubiquiti Networks Inc. 2014
Hit any key to stop autoboot: 0
Board: Ubiquiti Networks AR7241 board (e502-18.0101.002e)
0. Name = u-boot, offset = 0, start_addr=9f000000, size=262144,start_sector=0, end_sector=3
1. Name = u-boot-env, offset = 40000, start_addr=9f040000, size=65536,start_sector=4, end_sector=4
2. Name = kernel, offset = 50000, start_addr=9f050000, size=7733248,start_sector=5, end_sector=122
3. Name = cfg, offset = 7b0000, start_addr=9f7b0000, size=262144,start_sector=123, end_sector=126
4. Name = EEPROM, offset = 7f0000, start_addr=9f7f0000, size=65536,start_sector=127, end_sector=127
UBNT application initialized
## Booting image at 9f050000 ...
Bad Magic Number
Boot the initramfs from RAM. (load to 0x81000000 then bootm 0x81000000). Then scp the sysupgrade file to /tmp and install it with the sysupgrade command.
The "factory" file doesn't apply here. It was useful to install directly over factory firmware, but that only works on very old versions that don't check for a signature.
