Upcoming Maintenance Alert:

The UBNT Community will be upgraded at 5pm MDT on April 25th. During this time the community forums will be set to read-only status.

Learn more

×
Reply
New Member
Posts: 28
Registered: ‎05-05-2013
Kudos: 5

Re: HOWTO: Unbrick your UniFi AP

Are there any more commands to run while using terminal via usb to ttl cable? I am able to TFTP the firmware file to the unifi pro, but for some reason it never seems to install. Are there any more commands to run before you TFTP the firmware i.e. unprotecdt the firmware or something to that effect? Please see image below for behavior. It never goes through the install process of the firmware, just simply uploads quick and reboots basically. If anyone could help I would be very appreciative. 

help.jpg

New Member
Posts: 28
Registered: ‎05-05-2013
Kudos: 5

Re: HOWTO: Unbrick your UniFi AP

I think the issue may relate to the mtdparts configuration, but I am not sure. Does anyone know how to restore this back to factory default? I just want to get this system working else I will need to return it to the seller Man Sad

New Member
Posts: 28
Registered: ‎05-05-2013
Kudos: 5

Re: HOWTO: Unbrick your UniFi AP

Would $20 dollars paypal entice anyone for helping me fix this issue lol? 

Ubiquiti Employee
Posts: 7,053
Registered: ‎01-28-2013
Kudos: 8351
Solutions: 574
Contributions: 20

Re: HOWTO: Unbrick your UniFi AP

reset mtdparts to default? "mtdparts default"

It should accept the firmware without TFTP via serial TTL. Keep in mind that it voids the warranty by opening the device (as stated earlier in this thread). If it doesn't accept the firmware it sounds like something else is happening with the device... We always recommend the soft TFTP method before opening any device under warranty as it fixes most software related issues.

Thanks,
Mike

New Member
Posts: 28
Registered: ‎05-05-2013
Kudos: 5

Re: HOWTO: Unbrick your UniFi AP

Thanks for the reply Mike, I did perform that command yesterday before flashing and it did not seem to make a difference. The soft TFTP method did not work that is why I had to resort to a TTL connection since it never went into TFTP mode using the reset switch. Is there a way to manually setup the mdtparts so that it has the correct settings? Else could it be something else causing the firmware not to actually install? Is there a way re-flash uboot? 

Ubiquiti Employee
Posts: 7,053
Registered: ‎01-28-2013
Kudos: 8351
Solutions: 574
Contributions: 20

Re: HOWTO: Unbrick your UniFi AP

[ Edited ]

you're welcome.

you have email, at the account listed on your profile.

New Member
Posts: 28
Registered: ‎05-05-2013
Kudos: 5

Re: HOWTO: Unbrick your UniFi AP

Pefect, thank you very very very much! I will try that tonight and let you know.

Ubiquiti Employee
Posts: 7,053
Registered: ‎01-28-2013
Kudos: 8351
Solutions: 574
Contributions: 20

Re: HOWTO: Unbrick your UniFi AP


unifinoob wrote:

Pefect, thank you very very very much! I will try that tonight and let you know.


You're very welcome!

Emerging Member
Posts: 46
Registered: ‎03-02-2011
Kudos: 9
Solutions: 1

Re: HOWTO: Unbrick your UniFi AP

Hi there

I have a Unifi LR that I am trying to resurrect using a TTL cable (its died just out of warranty - sigh!)

when powering up it, more often than not, instantly starts with a solid orange LED and I get nothing on the console

 

Occasionally (circa 1 in 20 power ups) It instantly comes on with solid green LED and I get

U-Boot unifi-v1.2.1.71-g529c499d (Dec 21 2012 - 12:50:21)

in the terminal, but nothing more and I cannot type anything

I guess uboot is very corrupted

Is there a solution??

Thanks

Keith

New Member
Posts: 3
Registered: ‎02-09-2014

Re: HOWTO: Unbrick your UniFi AP

Hello im using this option but when I type ur and hit enter I get this ( unknown command try help ) so any help pls
New Member
Posts: 8
Registered: ‎02-27-2014
Kudos: 2

Re: HOWTO: Unbrick your UniFi AP

thanks very very much, work for me Ubnt Banana

New Member
Posts: 8
Registered: ‎02-27-2014
Kudos: 2

Re: HOWTO: Unbrick your UniFi AP

The problem was that my machine just like your machine's problem was solved with this method.

New Member
Posts: 13
Registered: ‎02-04-2014

Re: HOWTO: Unbrick your UniFi AP

[ Edited ]

Hello there!

So, it's my turn to ask some questions about unifi restore. I've got bricked ap-lr. When I try to put it in tftp-mode by giving "urescue" via ttl — i have success, but then in tftp mode it doens't answer the ping request — so it doesn't take the image via tftp. I mean, nothing happens — just spinning text cursor in terminal. How can I upload firmware by serial connection?

 UPD: I should give more information, I suppose.

1. Device in bootloader mode.

2. There are no tftp packets going through eth, Wireshark doesn't see anything.

3. I use tftpd32 as a client — no activity when I press "Put" button.

 

Maybe are there any guide or FAQ about work with JTAG on these devices? 

New Member
Posts: 8
Registered: ‎02-27-2014
Kudos: 2

Re: HOWTO: Unbrick your UniFi AP

When the device is in tftp mode not ping devices
Just in case the device is tftp server command tftp-i 192.168.1.20 PUT [path to file] \ firmware.bin run at the proper time and careful Using the Windows integrated TFTP client the command to prepare is again true Astfmrahl repeat.
If the device is not in tftp mode boot loader mode, the device has a problem with jtag method can solve this problem, which unfortunately I have not got enough knowledge in this field. I saw it as soon as your device

Prior to beginning the TFTP recovery, identify the correct firmware by going into your controller. You can find the correct fw path on your controller for the device you need to revive by using:

  • The chart found HERE, or
  • The following file on the controller: [unifi_base_dir]/dl/firmware/bundles.json

For eg., I have a Debian 7 x64 controller, ver. 3.1.3.2187, and I needed to revive a Unifi AP std, so my path was:  /usr/lib/unifi/dl/firmware/BZ2/3.1.3.2187/firmware.bin

Then, 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).

Follow the steps to unbrick your UAP:

  1. Set your PC to be able to access the bricked unit and prepare the firmware file:
  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.
    • Using the Windows integrated TFTP client the command to 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 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. Reconnect holding the reset button for ~7 seconds (green led will flash once) -> release reset button and wait for the device to stabilize again.
  8. After device is stabilized, power cycle it again, and you are good to go on adopting the device in the controller again.

 

New Member
Posts: 4
Registered: ‎08-20-2013

Re: HOWTO: Unbrick your UniFi AP

Hi!

I´m trying to recovery a dead Unifi UAP, if anyone can help...

- The controller show UAP (with IP 192.168.1.20) but UAP don´t answer ping.
- The controller fails to adopt this UAP.
- TFTP don´t work, becausa UAP don´t answer ping...  is strange, because he appears in Unifi Controller.

I´m conected by serial console, and i have a terminal with the UAP...  have any command to execute for send a new firmware by serial?

(I´m already tryed urescue, but don´t work.  TFTP server starts but don´t answer client)

New Member
Posts: 18
Registered: ‎10-16-2013
Kudos: 4

Re: HOWTO: Unbrick your UniFi AP

[ Edited ]

Does anyone have a how to on reloading the uboot?  I have reloaded with every version of the firmware that I can find from version 2 up to the newest 3.  All the firmwares load fine into the unifi AP (just two regular AP's) via TFTP put.  The unit reboots after the load.  The TTL cable shows "booting..."  and thats the last I see of it.  No orange light.  The only two that show are the power LED (D29) and the network (D30) one blinks every once in a while  Is there a way of zeroing out the memory and reloading everything (uboot, firmware, etc) on these units to try to see if I can get them to work?

EDIT: I have officially gotten them to both flash orange to show waiting adoption.  I know there is normally a timeout for the AP's and then they turn to solid orange, but that never happens.  They just keep flashing.  I also can't get either one to adopt though on the unifi console.

I have also tried ymodem transfer of the binary.  I am not sure what to do next after the transfer, but if someone has any insite, that would be greatly appreciated.

EDIT EDIT:  I got one unit to adopt, but as soon as it was rebooted, now I am getting "LZMA ERROR 1 - must RESET board to recover."  the uboot is unifi-v1.3.3.124-ge1a2c421 (Sept 27 2013 - 13:13:38)

Board: Ubiquiti Networks AR7241 board (e502-6.0101.002e)
DRAM:  64 MB
Flash:  8 MB
Net:   eth0, eth1
Hit any key to stop autoboot:  1

U-Boot unifi-v1.3.3.124-ge1a2c421 (Sep 27 2013 - 13:13:30)

Board: Ubiquiti Networks AR7241 board (e502-6.0101.002e)
DRAM:  64 MB
Flash:  8 MB
Net:   eth0, eth1
Hit any key to stop autoboot:  0
## Booting image at 9f050000 ...
   Image Name:   MIPS Ubiquiti Linux-2.6.32.33
   Created:      2014-02-25  22:47:39 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    918358 Bytes = 896.8 kB
   Load Address: 80002000
   Entry Point:  80002000
   Verifying Checksum at 0x9f050040 ...Bad Data CRC
ar7240> urescue
Setting default IP 192.168.1.20
Starting TFTP server...
Using eth0 (192.168.1.20), address: 0x81000000
Waiting for connection: checksum bad
checksum bad
checksum bad
checksum bad
checksum bad

Receiving file from 192.168.1.254:50137
Received 5217778 bytes
Firmware Version: BZ.ar7240.v3.1.10.2519.140225.1443
Setting U-Boot environment variables
Will not overwrite u-boot partition! Skipped.
Copying partition 'kernel' to flash memory:
        erasing range 0x9F050000..0x9F13FFFF: ............... done
Erased 15 sectors
        writing to address 0x9f050000, length 0x000f0000 ...
write addr: 9f050000
Copying partition 'rootfs' to flash memory:
        erasing range 0x9F150000..0x9F52FFFF: .............................................................. done
Erased 62 sectors
        writing to address 0x9f150000, length 0x003e0000 ...
write addr: 9f150000

Firmware update complete.

Resetting...

U-Boot unifi-v1.3.3.124-ge1a2c421 (Sep 27 2013 - 13:13:30)

Board: Ubiquiti Networks AR7241 board (e502-6.0101.002e)
DRAM:  64 MB
Flash:  8 MB
Net:   eth0, eth1
Hit any key to stop autoboot:  0
## Booting image at 9f050000 ...
   Image Name:   MIPS Ubiquiti Linux-2.6.32.33
   Created:      2014-02-25  22:47:39 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    918358 Bytes = 896.8 kB
   Load Address: 80002000
   Entry Point:  80002000
   Verifying Checksum at 0x9f050040 ...OK
   Uncompressing Kernel Image ... ERROR: LzmaDecode.c, 543

Decoding error = 1
LZMA ERROR 1 - must RESET board to recover

Resetting...

U-Boot unifi-v1.3.3.124-ge1a2c421 (Sep 27 2013 - 13:13:30)

Board: Ubiquiti Networks AR7241 board (e502-6.0101.002e)
DRAM:  64 MB
Flash:  8 MB
Net:   eth0, eth1
Hit any key to stop autoboot:  0
## Booting image at 9f050000 ...
   Image Name:   MIPS Ubiquiti Linux-2.6.32.33
   Created:      2014-02-25  22:47:39 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    918358 Bytes = 896.8 kB
   Load Address: 80002000
   Entry Point:  80002000
   Verifying Checksum at 0x9f050040 ...Bad Data CRC
ar7240>

Edit Edit Edit: Finally got the unit to boot hopping from firmware to firmware.  When loaded with 2.4.6, I can get the AP to broadcast and then I can adopt it on the unifi console.  Upon adoption, the AP turns green.  I can see it on the list with no wireless channel and I try to change the IP to a manual one, but the settings show saved, but the settings never take and it still uses a DHCP address.  I cannot SSH into it, but I do get a login for it.  Frustrated, I upgrade the firmware to 3.1.10 and the unit reboot about every 2 to 3 minutes.  I cannot get the console to display anything but "upgrading" and none of the settings seem to be sticking for the IP address or anything else for that matter now with the AP.

After resetting the AP back to factoryand removing it from the console, I connect it up to my laptop and SSH into the default IP.  From there it still shows the 2.4.6 at the begining after login.  I reboot it and go into TFTP with the reset button on boot.  Put the 3.1.10 image to the device.  Flashes with no errors and then reboots.  Upon initial boot, I get the "Verifying Checksum at 0x9f050040 ...Bad Data CRC" and the unit pauses at the command line.

New Member
Posts: 18
Registered: ‎10-16-2013
Kudos: 4

Re: HOWTO: Unbrick your UniFi AP

Does anyone have any ideas?

New Member
Posts: 5
Registered: ‎10-02-2013
Solutions: 1

Re: HOWTO: Unbrick your UniFi AP

I am having the same issue. I can downgrade to 2.4.6 and everything works fine. Every time i try to upgrade back to 3.1.10 the device loses its center light and goes into a continuous rebooting cycle. I have three devices out of 140 performing this way. Only one says bad data CRC. The other boot without error, but then immediately reboot. Another post suggested this could be related to an update UBNTs released that has the firmware validate that the devices are authentic. These are all authentic devices.

Any help would be appreciated. 

 

New Member
Posts: 21
Registered: ‎08-16-2013
Kudos: 14

Re: HOWTO: Unbrick your UniFi AP


Goodman_Wa wrote:

I am having the same issue. I can downgrade to 2.4.6 and everything works fine. Every time i try to upgrade back to 3.1.10 the device loses its center light and goes into a continuous rebooting cycle. I have three devices out of 140 performing this way. Only one says bad data CRC. The other boot without error, but then immediately reboot. Another post suggested this could be related to an update UBNTs released that has the firmware validate that the devices are authentic. These are all authentic devices.

Any help would be appreciated. 

 


This sounds about right. Don't know much about the inner workings, but if the APs are working fine with one version and fail with another one, I would contact service/reseller.

Even if out of the warranty period, I suspect they would help with the issue, as it could be an involuntary induced flaw.

I don't think you can do much on your own to fix this unless your in micro programming, embedded linux, assembler and other fancy stuff. And unless you have some tons of time for debugging. ;-)

New Member
Posts: 21
Registered: ‎08-16-2013
Kudos: 14

Re: HOWTO: Unbrick your UniFi AP

@lostinignorance

It is something there corrupting the image you upload, or the checksum possible issue Goodman_wa mentioned. Going from the top of the probable issue chain down, I would triple check: file sanity after download, network link quality between the PC and the AP (switches, cables, connectors, NICs etc etc).

This sure looks intereseting:

Waiting for connection: checksum bad
checksum bad
checksum bad
checksum bad
checksum bad

Receiving file from 192.168.1.254:50137
Received 5217778 bytes
Firmware Version: BZ.ar7240.v3.1.10.2519.140225.1443

Check if the received byte count concurs with the byte count of the image on the computer. If not, something is wrong with your connection.

If communication with the AP is not flawed in any way and the image file is not corrupted, then you may have ran into a bad flash chip. Afaik, the bad sectors should show up as warnings when flashing from uboot, but with all the uboot and nandwrite custom builds out there you can't be sure. You usually have a checksum after downloading via tftp to the device, beside the byte count, on most devices, but here you don't. So....

Also, no error in here, when writing, in case of a bad nand flash a skip block warning should be shown:

Will not overwrite u-boot partition! Skipped.
Copying partition 'kernel' to flash memory:
        erasing range 0x9F050000..0x9F13FFFF: ............... done
Erased 15 sectors
        writing to address 0x9f050000, length 0x000f0000 ...
write addr: 9f050000
Copying partition 'rootfs' to flash memory:
        erasing range 0x9F150000..0x9F52FFFF: .............................................................. done
Erased 62 sectors
        writing to address 0x9f150000, length 0x003e0000 ...
write addr: 9f150000

Firmware update complete.

It could also be the case that this build ignores bad blocks and just writes data there. And when you try to read back you get inconsistent data.

I would say you either have a corrupted image that you wrote to the AP, or a bad flash, with a bad block in the kernel address area. This may give out the inconsitent reads: once it checksums ok but fails to validate lzma, once it fails checksum and so on.

   Verifying Checksum at 0x9f050040 ...OK
   Uncompressing Kernel Image ... ERROR: LzmaDecode.c, 543

Decoding error = 1
LZMA ERROR 1 - must RESET board to recover
   Verifying Checksum at 0x9f050040 ...Bad Data CRC
ar7240>

 

As this only happens with fw ver >2.4.6, it might also be a nand partitioning change in the newer fw. So the load should not be done at the 0x9f050040 address, but from somewhere else.

You could try to open the image with a hex editor and check the partition padding, then figuring out the partition layout and addresses.
If you played before with uboot, embedded linux and nands, this should not be news for you.
Then if the addresses are wrong you can change the uboot enviroment and see how it goes from there

Also, from what I know, that CRC error in the kernel might also mean a bad build, not necessarily a bad hw or env address. A bad kernel pack in that image might throw that. I get that every time I screw up my kernel builds on embedded boards. And this means alot, as I am not very experienced. :-)

Reflashing uboot will not really help, I see a well functioning bootloader there. Maybe a newer build, but this needs to be provided by Ubiquity, as this is very device specific.

If you don't have knowledge and time to dive into this, I would advise you contact support. OR if you don't have warranty or a helpfull reseller, you might want to throw the AP in a corner and wait to have time to look into it.

OR, you could just stay on 2.4.6 and use these like this until you find time to play around with it. Just be careful not to drop the bomb and erase the uboot partition. ;-)

Anybody @Ubiquity pitch in here, pls? :-)

 

Cheers.

Reply