Solved: Re: HOWTO: Unbrick your UniFi AP - Page 5

GreatWhiteDan · ‎02-01-2015

stevebird wrote:

** BE CAREFUL You can make the situation worse than it already is by miss typing the commands, getting a memory address wrong etc.. ** BE CAREFUL ** (Worth saying twice) And remember your results may vary to mine. I have sucuessfully recovered eleven unify's that would not recover via the urescue process using the below. Each and every one is now updated to 2.4.6.2178 and is working perfectly.

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

Board: Ubiquiti Networks AR7241 board (e502-6.0101.002e)
DRAM: 64 MB
Flash: 8 MB
*** Warning - bad CRC, using default environment

***           saving default environment ...
Un-Protected 1 sectors
Erasing Flash.... done
Erased 1 sectors
Writing to Flash... write addr: 9f040000
done
Protected 1 sectors
Net:   eth0, eth1
Hit any key to stop autoboot: 0
## Booting image at 9f050000 ...
   Image Name:   MIPS Ubiquiti Linux-2.6.15-5.2
   Created:      2012-02-24 16:55:55 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    730087 Bytes = 713 kB
   Load Address: 80002000
   Entry Point: 80002000
   Verifying Checksum at 0x9f050040 ...Bad Data CRC

ar7240> mtdparts default
ar7240> saveenv
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash.... done
Erased 1 sectors
Writing to Flash... write addr: 9f040000
done
Protected 1 sectors
ar7240> tftp 83000000 2.4.6.2178/mtdblock2
Using eth0 device
TFTP from server 192.168.1.254; our IP address is 192.168.1.20
Filename '2.4.6.2178/mtdblock2'.
Load address: 0x83000000
Loading: #################################################################
         #################################################################
         #################################################################
         ##########
done
Bytes transferred = 1048576 (100000 hex)
ar7240> protect off all
Un-Protect Flash Bank # 1
ar7240> erase 0x9f050000 +0x100000
................ done
Erased 16 sectors
ar7240> cp.b 0x83000000 0x9f050000 0x100000
Copy to Flash... write addr: 9f050000
done
ar7240> cmp.b 0x83000000 0x9f050000 0x100000
Total of 1048576 bytes were the same
ar7240> tftp 83000000 2.4.6.2178/mtdblock3
Using eth0 device
TFTP from server 192.168.1.254; our IP address is 192.168.1.20
Filename '2.4.6.2178/mtdblock3'.
Load address: 0x83000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ######
done
Bytes transferred = 6684672 (660000 hex)
ar7240> erase 0x9f150000 +0x660000
...................................................................................................... done
Erased 102 sectors
ar7240> cp.b 0x83000000 0x9f150000 0x660000
Copy to Flash... write addr: 9f150000
done
ar7240> cmp.b 0x83000000 0x9f150000 0x660000
Total of 6684672 bytes were the same
ar7240>
ar7240> reset

Resetting...

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

Board: Ubiquiti Networks AR7241 board (e502-6.0101.002e)
DRAM: 64 MB
Flash: 8 MB
*** Warning - bad CRC, using default environment

***           saving default environment ...
Un-Protected 1 sectors
Erasing Flash.... done
Erased 1 sectors
Writing to Flash... write addr: 9f040000
done
Protected 1 sectors
Net:   eth0, eth1
Hit any key to stop autoboot: 0
## Booting image at 9f050000 ...
   Image Name:   MIPS Ubiquiti Linux-2.6.15-5.2
   Created:      2013-10-08 18:37:43 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    729748 Bytes = 712.6 kB
   Load Address: 80002000
   Entry Point: 80002000
   Verifying Checksum at 0x9f050040 ...OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

Booting...

And from then on its accessable again from the regular Unify web interface.

I've invested time in reading about U-Boot and what commands were available and knowing linux and networking already, together with programming knowledge this is how I have bought it all together to transfer the parts of the image nessasary and write then directly,
What you will also need is the seperate parts of the NAND flash that make up the whole filing system, I only used the kernel and rootfs parts though. You will also need a working tftp server for the unify to pull the partitions from, but you'll probably have this already since you've tried the urescrue and found it not wor work.
To get the working partitions you'll need another working unify that you can ssh into and then extract from and copy to your tftp server ready to be transfered. I did try and work out a way to extract them from the firmware.bin file but gave up and went for the shorter route.

Anyone choosing to use the above method. It works VERY well. You need to basically flash over your partitions with a good image. I could not find the image files, so I made them and recovered several units that someone had flashed a 3rd party OS to, so they could not be flashed back.

Basically, as described above, in summary use the commands:

mtdparts default

saveenv

protect off all

tftp 83000000 2.4.6.2178/mtdblock2

erase 0x9f050000 +0x100000

cp.b 0x83000000 0x9f050000 0x100000

cmp.b 0x83000000 0x9f050000 0x100000

tftp 83000000 2.4.6.2178/mtdblock3

erase 0x9f150000 +0x660000

cp.b 0x83000000 0x9f150000 0x660000

cmp.b 0x83000000 0x9f150000 0x660000

reset

One of my units did not boot after this, but showed, an invalid firmware after that, then I just did a

dhcp

tftp 0x81000000 firmware.bin

boot

That upgraded the unit to the latest firmware since it saw the right OS and correct partitions, and recovered as normal.

Attached is a zip file of all the MTD partitions in a binary format that were pulled from the good AP.

As usual, use at your own risk.... I have nothing to do with what happens.

ayahdifa · ‎06-03-2015

You can try simple ways for nanostation XM

Download FW 5.5 or below

at uboot console you can try urescue -f

then ftp put the firmware binary urescue -f will flash include U-Boot 1.1.4.2-s594

after sucessfull update unit will reset enter to uboot mode again command mtdparts default, saveenv then reset

unit will booting with old firmware including old uboot

hope this help

agisofttm · ‎02-12-2014

Are someone have all mtdblocks from UniFI-AP-LR? We try to recover one with mtdblocks from GreatWhiteDan, it was success, but i believe that AP-LR is different and the result is there is no Wireless right now.

Kind Regards

GreatWhiteDan · ‎02-01-2015

Once you get it recovered with the mtdblocks I had posted, you should be able to do a normal firmware upgrade. Try using the normal AP firmware to upgrade to the latest version. Or you could downgrade to an older version, then upgrade to the latest to force an full upgrade as well.

agisofttm · ‎02-12-2014

Actually we tried - the problem is that our customer was playing around with mtdblock5, and offcourse all of MAC address and may other information is now wrong or missing. We've managed to adopt unit with old version, but when we try to upgrade to new one, adoption is gone and we have Error A12 in serial console. Thats why I want to try with mtdblocks from working version of AP Long Range.

Thank you again for support GreatWhiteDan

stevebird · ‎03-09-2014

One of my units did not boot after this, but showed, an invalid firmware after that, then I just did a
dhcp
tftp 0x81000000 firmware.bin
boot

Could you make that "firmware.bin" file available please - I've got a unit that is very unhappy and likely damaged nand. but its worth a last try using this method.

Thanks,

stevebird · ‎03-09-2014

agisofttm wrote:
Actually we tried - the problem is that our customer was playing around with mtdblock5, and offcourse all of MAC address and may other information is now wrong or missing. We've managed to adopt unit with old version, but when we try to upgrade to new one, adoption is gone and we have Error A12 in serial console. Thats why I want to try with mtdblocks from working version of AP Long Range.

Thank you again for support GreatWhiteDan

That Ap may well be at the point were you cannot do anything with it.

I've been trying to get the initial setup util from UBNT, when they build the AP's they must connect it to a system that blows in a base setup to take it onto the next stage. Why wont they make it available....

agisofttm · ‎02-12-2014

I believe that eprom is messed up, and that's why there is no wireless - when i upload old firmware everything look fine, except Wifi, i will try third parity firmware to test wifi card, but it will be good to have mtdblocks - i just have only one Ap-Lr unit and cannot read good blocks and i'm absolutely sure that hardware between Unifi AP and Unifi Ap-Lr is different

GreatWhiteDan · ‎02-01-2015

Sorry I can not be futher assistance.

GreatWhiteDan · ‎02-01-2015

I can not say if the hardware is the same or not, but I can confirm that I have used those same mtdblocks to recover both the LR and the regular APs. I have recovered 3 of them that I converted to 3rd party firmware. I did not know at the time that it would brick them. Since then I have not converted anymore of them. I am just using them as is and am happy with what they are.

Good luck

agisofttm · ‎02-12-2014

GreatWhiteDan - Thank you again - i'll try again tomorrow

EricE · ‎01-10-2012

stevebird wrote:
Why wont they make it available....

Counterfiters, people trying to load their software onto other vendors hardware (selling hardware is how UBNT makes their money since they offer the management software for free).

That's two reasons. They may fix it, but I suspect you may have to just rebuy. Luckily their gear is pretty inexpensive so it's not that burdonsome.

When you receive a solution to your question/issue, don't forget to mark your thread as solved and to give kudo's to the people who have helped you out!

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

dywilson · ‎03-18-2014

HI GreatWhiteDan

First, Thanks for your info here - it is great and I have recovered a few UAP's that were otherwise not responding to soft tftp efforts.

I was wondering though if you could explain how you copied the mtdblock2 and mtdblock3 off of a working UAP.

The UAP-Pro appears to be quite different and I wanted to get the mtdblocks for the UAP-Pro.

I do have a good working UAP-Pro.

The mtdparts is clearly different.

device nor0 <ath-nor0>, # parts = 5
 #: name			size		offset		mask_flags
 0: u-boot                	0x00040000	0x00000000	0
 1: u-boot-env            	0x00010000	0x00040000	0
 2: jffs2                 	0x00f60000	0x00050000	0
 3: cfg                   	0x00040000	0x00fb0000	0
 4: EEPROM                	0x00010000	0x00ff0000	0

I was also trying to correlate the commands you used for the mtdparts of a UAP so I could try similar commands but suitable for the UAP-Pro.

eg: cp.b 0x83000000 0x9f050000 0x100000

appears to copy the mtdblock2 from the temporary 0x83000000 location into 0x9f050000

But the mtdparts command on the UAP shows that block at 0x00050000

Is there something special about the 9f.

Why the conversion of 0x00050000 to 0x9f050000

Dave

GreatWhiteDan · ‎02-01-2015

I copied the mtdblocks from a good unit that was fully booted up normally, and then I ssh into the unit and do a normal linux dd command and copy the partitions to files. At least that is how I think I did it... ;p it has been a few night of sleep since then, and the bit bucket has been drained many times. I am 99% certain I was in an SSH session to do it, becuase I could not find a good way to pull the mtdparts from the uboot unterface.

stevebird · ‎03-09-2014

If you've got another linux box, it can be done quite crudely

first make sure you can ssh into your working AP;

ssh -l <username> <ip_of_working_ap>

you'll need to know your username/password combo for the AP, the default is ubnt/ubnt but you might changed it, mine is admin/(not saying)

Then once you can get to a prompt, just logout again.

Then using the remote command method ;

ssh -l <username> <ip_of_working_ap> cat /dev/mtdblock0 > mtdblock0

You'll end up with a copy of the mtdblock0 partition in your local directory. just repeat for the other partitions by changing the mtdblock0 to mtdblock1 2,3,4 etc..

You could go through a longer process of piping dd through the session etc, but in this case cat works just as well.

Like I say, crude, but does work...

stevebird · ‎03-09-2014

GreatWhiteDan wrote:
One of my units did not boot after this, but showed, an invalid firmware after that, then I just did a
dhcp
tftp 0x81000000 firmware.bin
boot

Have you got a copy of that firmware.bin file you can place somewhere please?

WifiCatalogue · ‎03-23-2016

If the Unifi AP doesn't respond at ping 192.168.1.20 after reset, should it be considered with damaged bootloader or hardware failure? The AP is changing lights between orange, green and off every 1 second.

PS I have done the process with soft recovery and i have setup my pc in 192.168.1.10/24 address.

The AP lost power during upgrade.

WifiCatalogue · ‎03-23-2016

Sorry, AP isnt supposed to reply to ping in this state. I proceeded with the tftp copy and AP is operational again.

mistrykm4u · ‎02-05-2014

Hi.. Steve

can you please give me your FTP server username & password.

mistrykm4u · ‎02-05-2014

please guide me how to download mtgdblock via ssh

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Re: HOWTO: Unbrick your UniFi AP

Company

In the News

Training

Buy Now

Social