10-07-2012 08:59 AM
To Unbrick, you'll need a 3.3v capable Serial to TTL cable. I used a USB to serial cable like this one:
Note: You CANNOT use a USB to RS-232 cable! That type is the worng polarity and it outputs high-voltage (+/- 10V) and could destroy your AP! Also: do NOT connect the power wire to anything!
This procedure should recover any AP with corrupted config or firmware. It will not fix units that have lost their bootloader somehow (rare) or if they have electrical damage (ESD/Lightning).
Connect your USB to TTL adapter to your PC, and now we'll connect the other end to the header inside. This is a 4 pin connector with bare gold pins sticking up. You only should connect 3 wires, GND, TX, and RX. (DO NOT use the Power or Vcc wire from the USB to serial adapter!)
The pinout seems to vary across models, but GND is always on one end, and it's easy to determine, as it's connected to the backplane. You can either use a meter to check continuity to the backplane (same as the silver housing on the ethernet jack), or just look at the board closely and see which end has the copper foil connected to it. (a magnifying glass makes this easy)
Once you have GND connected, fire up a terminal program. I used minicom on Ubuntu, but you can use hyperterm or teraterm (free) on windows. Be sure to set it for 115k, 8N1. (115,200 baud, 8 bit, 1 stop, No parity, and no flow control.)
You can confirm the terminal is working correctly by using a small paperclip to connect the TX and RX on your cable ends together. If you are all good to go, you should see an echo of everything you type on the screen.
Ok, now disconnect your test jumper (paperclip) and connect the RX wire to the pin adjacent to GND on the AP. Apply power to the AP, if you don't see stuff printing on the screen within a second or two, move the RX wire to the next pin on the AP, cycle power and look for the text again. If you see a bunch of garbage, it's likely the baud rate is incorrect. Try different ones until the text is readable. The UniFi Outdoor is 115,200.
Now that you've found the correct RX pin, now you've got to find the one for TX. It's always next to the RX, so at most you have 2 locations to try. Connect TX to one of these 2 pins, power-cycle the AP again and immediately begin hitting ESC rapidly over and over. If the bootup messages stop, BINGO! You're in! If not, try the other location.
Once you are in, all you have to do is type "urescue" to put the unit in TFTP accept mode. Configure a PC with the IP of 192.168.1.254 and connect it to the AP directly. (port 1 if there are 2 ports) Then TFTP the correct firmware.bin (using bin mode) to the AP at 192.168.1.20. You will see the progress on the terminal screen. Wait fully until the AP reboots before you remove power! Note that the AP doesn't respond to pings while in this mode.
Make a note of the pinout for future use to save time. (I forgot to) Post them here for each model!
I found that 2.2.5 seems to be the "safest" to revert to. Note that this WILL NOT overwrite the config, so after flashing use the reset button or login at the terminal and issue the syswrapper.sh restore-default command. After that, it's like a brand new "fresh" AP!
10-07-2012 09:01 AM
PLEASE put come code in the bootloader to allow us to TFTP rescue without cracking the case! On some of your products you can do this with the button during bootup. Another way I've seen looks for an ICMP ping during bootup, and if it sees one, it enters TFTP accept mode.
It would also be useful to include a special version of the firmware that erases the config, so it makes it easier to restore "bricked" units with corrupted config. Or even just a separate config erase BIN file, so there is no need to regress firmware.
10-09-2012 06:16 AM
I used GPSGate to assign ports and both teraterm and hyperterm dont seem to connect to the AP.
Cable i used is as you mention above, but no success.
I think i'm mistaking on the ports assignement and connection to terminal.
You also mention not to connect the VCC pin. OK i did, but i powered-up the AP from its POE adapter. Is it correct?
10-09-2012 04:05 PM
(I have not checked the pinouts).
Biggest Ubiquiti Distributor in Australia
Certified airMAX Instructor
Certified UniFi Instructor
Certified Routing and Switching Instructor
10-09-2012 04:29 PM
In Linux they are automatically assigned, just check the kernel messages (dmesg).
Do not hook up the Vcc, it is not needed and could try to power the AP from a higher voltage than it's ok with. (damage)
11-12-2012 03:26 PM
green led is blinking occasionally every 15 -20sec
controler cant see unit. while connected to pc UAP-LR tries to connect for 5 sec then disconnecting after 2 sec and so on.
11-12-2012 03:41 PM
while connected to pc UAP-LR tries to connect for 5 sec then disconnecting after 2 sec and so on.
Can you SSH into it? If so, what happens if you issue the set-inform? Does it then see the controller?
Is the firmware in it the same as the controller? If not you can manually update the firmware and that will more than likely solve it.
Having wifi problems? Take a look here first: https://help.ubnt.com/hc/en-us/articles/221029967-UniFi-Debugging-Intermittent-Connectivity-Issues-on-your-UAP
11-12-2012 03:47 PM
11-15-2012 05:15 AM
No Data,just blank screen.
What else can i do to bring my unifi back to life?
Is it possbile to reflash using jtag?
08-16-2013 10:09 AM - edited 10-04-2013 05:59 AM
Sorry for reviving this necro-thread.
Not sure if this is still generally available, but you can enter the TFTP mode in the bootloader and revive a bricked unit using the bellow procedure without cracking open the chassis.
Works on all recent Unifi APs, all models, as far as I tested.
- Set your PC to be able to access the bricked unit and prepare the firmware file:
- get the correct firmware by going to your controller:
You can find the correct fw path on your controller for the device you need to revive by using:
a) The bellow tables:
b) The following file on the controller:
Thank you UBNT-MikeD for the updates.
For eg., I have a Debian 7 x64 controller, ver. 184.108.40.2067, and I needed to revive a Unifi AP std, so path was:
- set a static ip on your PC's NIC from 192.168.1.0/24 range, but not 192.168.1.20 (this is the Unifi AP default TFTP IP).
2. Prepare your TFTP client to push the firmware.bin file so you can start it with just a hit of a button. Do not start the push yet.
I use the Windows integrated TFTP client so to command I prepare is:
"tftp -i 192.168.1.20 PUT [path to file]\firmware.bin"
3. Unplug the bricked unit.
4. Plug the LAN connection of the PoE injector directly to your PC's NIC.
5. Keep the unit's reset button depressed and plug in network/PoE in the unit.
Keep the reset button depressed until you see the light cycling relatively fast through amber/green/off colours (~14 seconds from power on) -> Release it. Now the device is in TFTP transfer mode.
6. Engage the TFTP push command and wait. The device will write the firmware and it will reboot.
If you wait too long to start the tftp, the push will not work as the device will go stall. Please redo from step 3.
7. To ensure all goes clean, after the device gets stable (blinking or steady amber led), give it a reset:
Remove power, and reconnect holding the reset button for ~7 seconds (green led will flash once) -> release it and wait for the device to stabilize again.
8. After it stabilized, power cycle it again, and you are good to go on adopting the device in the controller again.
This method was designed after I cracked open some units and confirmed it by looking on the TTL console. So now this can be done blindly.
I do not guarantee that it will work on any Ubiquity unit, but it might save you the hassle of screw removal and ttl console hookup.
If it does not work, I believe it can do no harm more than it was already done in the first place.
If this is the case, you will need to either ask for qualified help from support or hookup a ttl cable and debug it, if you know what you are doing.
This will not work if the uboot bootloader has been damaged (tftp recovery is in uboot), or the board is electrically fried (duuuhhh! :-) )
If bootloader is damaged, a JTAG header is available (at least on recent Unifi AP units), so, if you know what you are doing and have a backup bootloader image, you can go that way. I have no knowledge of how to do this, but anyone that has is welcome to help and complete this thread with this valuable info.
08-16-2013 10:24 AM - edited 08-16-2013 10:32 AM
@razor: Maybe a biiiiit tooooo late. , but having garbage on your terminal screen is most of the times associated with a bad cable connection. Secure the cables properly.
I can confirm baud rate at 115200 on all models I tested.
My unit was in the same state, so if it is still broken, you can try my blind version of Phill's tutorial, as you have no console.
If revive not working, and still getting garbage on console, the bootloader may need rewriting via JTAG (I will get my hands on a jtag device and try to make a backup and put it here when I get the kicks of how to do it).
Or....worst situation, board is fried.
10-03-2013 05:25 AM
Thx Vali for the solution, I can confirm it works.
I had an Unifi AP bricked by the loss of power during upgrade.
Take note though that during tftp process it doesn't respond to ping and also that it takes about a minute to reboot after the tftp upgrade. Be patient.
10-03-2013 06:16 AM - edited 10-03-2013 06:21 AM
Yes, the soft method of TFTP does work in many scenarios. Keep in mind opening a UAP does void the warranty too. So that's reserved as a last ditch effort typically reserved for out of warranty units. Most of the time it shouldn't be needed though as the soft method should work. If it doesn't it usually indicates a hardware issue that won't be resolved with software flashing, but may be an exception to that (a reset by performing mtdparts default).
The soft method you mention looks very similar THIS method, but a written cleaner. Don't forget there are different firmware versions for different UAPs. So BZ2 does not "fit" all units. I like referencing the bundles.json file found in unifi_base/dl/firmware to find the matching firmware version for the appropriate UAP, but you can also reference the table found HERE which has a few of the models listed with which version they use.
10-03-2013 06:25 AM
Thanks for the reply. I tried avoid opening the case (in search of a serial...) and I manage to do it.
The file you mention (bundles.json) is exactly the one I used to find the right firmware.
So, now I have the AP working back again, without opening it.
10-04-2013 05:41 AM
Hmmm, never succeded to find THAT method, did not show up in searches, for some reason. Indeed would have helped me. :-)
About the BZ2 part, yeah, I wrote that in a bit of a hurry and slipped my mind....I just pasted the path there, a no brainer. :-) Thanks for the info about bundles.json, will update the post asap.
10-26-2013 12:47 PM
I have a UAP-US that we recently had go offline for some random reason. The unit is just outside of warranty and Ubiquiti stated they won't warranty the issue. I purchased a TTL cable as stated above. I am seeing the initial boot from the uboot image. Everything on the boot portion shows good. I am able to press and hold the reset and get it into the TFTP receive state. I have sent the firmware bin image via this method multiple times using the above link to determine the correct firmware.
My problem is after reloading the bin image, the TTL output shows "Booting..." yet nothing shows on the console after that. The AP never gets the orange blink to show waiting for adoption. It just sits at "Booting..." for as long as I leave it plugged in. When watching via the TTL cable when pushing the image, I get no errors when it clears the sectors and writes. The unit then reboots and just shows "Booting..."
Is there anything I can do with this unit, besides using it for trap shooting?