User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
mission:log:2016:03:18:harder-soft-unbricking-a-bricked-ubiquiti-unifi-uap-pro-ap [2016/03/18 15:56] – created chronomission:log:2016:03:18:harder-soft-unbricking-a-bricked-ubiquiti-unifi-uap-pro-ap [2016/06/09 20:48] (current) – [Solution 1] chrono
Line 3: Line 3:
 {{:mission:log:2016:03:18:ubiquiti-unifi-uap-pro-inside-with-serial-debug-connected-sideview.jpg|ubiquiti-unifi-uap-pro-inside-with-serial-debug-connected}} {{:mission:log:2016:03:18:ubiquiti-unifi-uap-pro-inside-with-serial-debug-connected-sideview.jpg|ubiquiti-unifi-uap-pro-inside-with-serial-debug-connected}}
  
-After re-deploying the Ubiquiti Unifi UAP-Pro at the new base-campit simply didn't work anymore. No DHCP reaction, nothing. Except for the LED blinking white sometimes, it seemed completely broken. After opening and attaching a terminal to the serial console, the boot output didn'look promising but at least it wasn't completely dead. So we had to get our hands dirty, pop the hood and hack around to fix this jffs2 issue and revive the AP without costly and probably long/painful RMA.+Re-deploying the Ubiquiti Unifi UAP-Pro with OpenWRT (instead of Unifi) at the new base-camp revealed a problem: it simply didn't work anymore. No DHCP reaction, no default IP, nothing. Except for the LED blinking white after a reset, it seemed completely broken. Opening the case and attaching a terminal to the serial console, revealed bootloader output that wasn't promising but at least it wasn't completely dead. So we had to get our hands dirty, pop the hood and hack around to fix this jffs2 corruption issue and revive the AP without costly and probably long/painful RMA. Maybe this knowledge can help you too.
  
 ===== The Symptom ===== ===== The Symptom =====
Line 58: Line 58:
 </WRAP> </WRAP>
  
-This may be due to the fact that it expects a bricked UBNT firmware and NOT an OpenWRT installation.+This may be due to the fact that this workflow expects a bricked UBNT firmware and NOT an OpenWRT installation.
 ===== Solution 2 ===== ===== Solution 2 =====
  
Line 178: Line 178:
 </code> </code>
  
-The firmware image is stored in RAM now and occupies **0xf60000** bytes. Writing it from there to flash memory directly may fail when the target area has not been erased or if it is write-protected. Let's take care of that first.+The firmware image is stored in RAM now and occupies **0xf60000** bytes. Writing it from there to flash memory directly may fail when the target area has not been erased or is write-protected. Let's take care of that first.
 ==== Step 4: Reset partition table to defaults ==== ==== Step 4: Reset partition table to defaults ====
  
Line 238: Line 238:
 ==== Step 6: Erase the corrupt jffs2 ==== ==== Step 6: Erase the corrupt jffs2 ====
  
-Figuring out the correct address and length was a bit difficult, uncertain, not well documented and took us quite a while, because we didn't want to brick it more by writing stuff somewhere other than we intended. Unfortunately, there was no documentation about the process of how we derived at that conclusion, but in the end we finally decided to start at address **0x9f050000** for the length of the jffs2 image as indicated by the tftp transfer (**0xf60000**) and the mtd partition size (**0xf60000**)+Figuring out the correct address and length was a bit difficult, unclear, uncertain, not well documented and took us quite a while, because we didn't want to brick it more by writing stuff somewhere other than we actually intended. Unfortunately, there was no documentation during the process of how we derived at that conclusion, but in the end we finally decided to start at address **0x9f050000** for the length of the jffs2 image as indicated by the tftp transfer (**0xf60000**) and the mtd partition size (**0xf60000**)
  
 <code> <code>