Téglásodott unifi AP javítás

A minap hoztak hozzám unifi ac-lr és ac-pro ap-kat. Az volt a jelenség, hogy maga készülék nem adott magárol életjelet, azaz nem világitott sem a fehér, sem a kék led…..

Hátha más is igy jár. Legyen hát egy leirat arról hogy hogy lehet visszahozni az életbe a unifi ap-t.


A minap hoztak hozzám unifi ac-lr és ac-pro ap-kat. Az volt a jelenség, hogy maga készülék nem adott magárol életjelet, azaz nem világitott sem a fehér, sem a kék led. Ellenben a switch-re dugva a switch porján a led világitott akkor is ha poe switch-re dugtam, és akkor is ha poe injektorral tápláltam meg. Első gondolatom az volt, hogy ez nem is inkább hardware-s probléma mind inkább szoftveres, azaz letéglásodott. Az ugrott be, hogy valamikor a 2000 es években, amikor még a linsys wrt54-gl sokat ért, nekem is sikerült letéglásitani azt, miközben a gyári szoftver helyére felynomtam a dd-wrt-t. Akkor azt jtag kábellel javitottam. Igy azt gondoltam,ha ez is csak egy ilyen upgrade miatt elromlott ap akkor esetleg javitható. 
Első körben szétszedtem, megmértem a panelen a feszültségeket és rendben találtam mindent.
Következő lépésben megtaláltam az uart-portot amibe nem volt beforrasztva a tüske sor, így beforrasztottam és már toltam is rá az usb UART adapteremre. A GND megtalálása egyszerű volt azomban az RX TX lábakkal játszani kellett mire megtaláltam melyik melyik láb. A 3,3v ot nem kötöttem be. A képen balról jobbra a következő a kiosztás:
GND RX TX 3.3V





Itt már látszott, hogy a boot folyamat elindul, de le is áll. Arra gondoltam, hogy ok ez a flash sérült, csináljuk azt amit a linksys esetében.  Azomban ebben az esetben nem ilyen egyszerű a dolog. Utána járva a unifi rendszer particioján olyan egyedi azonositók, és wifi adó kalibrációk vannak amiket nem szabad felül írni. Ok mondom mi van akkor, ha csak a firmware elejét írom újra, mondjuk a boot particiót.
Kértem egy működő ap-t és ssh-n belenéztem, és lekérdeztem a particióstáblát:
valahogy így néz ki a dolog:

BZ.v6.5.28# cat /proc/mtd

dev: size erasesize name

mtd0: 00060000 00010000 „u-boot”

mtd1: 00010000 00010000 „u-boot-env”

mtd2: 00790000 00010000 „kernel0”

mtd3: 00790000 00010000 „kernel1”

mtd4: 00020000 00010000 „bs”

mtd5: 00040000 00010000 „cfg”

mtd6: 00010000 00010000 „EEPROM”


első körben arra gondoltam, hogy az mtd0 particiot fogom irni ujra.
Ott a mérete hexában:0x60000 = 393 216 byte = 384 KiB
Szóval a stratégia megvan, kell egy flash programozo készülék, és egy csipesz.
Aliexpress-ről rendeltem egy ch341A programozót, és egy 16 lábú csipeszt hozzá.
Vita van arról, az interneten, hogy 5v os vagy 3,3v os programozot használj. És egyesek átalakitják ezt az irót,mint pl ebben a youtube videóban.
https://www.youtube.com/watch?v=-ln3VIZKKaE
chatgpt is javasolja hogy erre figyelj.
Viszont van ellen video is ahol elmagyarázza az ember hogy miért nem kell átalakítani.
https://www.youtube.com/watch?v=J8-Sh7DjiXw
Engem meggyőzött így ahogy kicsomagoltam a programozót úgy használtam ehhez a feladathoz.

Flashrom olvasása

Ezeken az ap-kon egy 16 lábú macronix25L12835F chip van,azomban a programozón 8 lábú chip-hez van kivezetés. Így kicsit zavarban voltam először, hogy akkor ez hogy is van? Kiderült hogy ebből a chip-bő létezik 8 lábú is, és 16 lábú is. A chip datasheet-je alapján megtaláltam mindkét chip lábkiosztását. 


A mellékelt ábrán látszik is, hogy hogy van a két eszköz lábkiosztása. Igy már be lehet kötni az programozóba, csak a csipeszen kell módosítani. Én fogtam és levágtam a kábel végéről a csatlakozót és szétszálaztam ezen a csipeszen az összes szálat, így jobban látszott, hogy melyik láb melyik szálhoz tartozik. És fogtam a programozóhoz kapott adaptert, és a fenti dokumentáció alapján beforrasztottam a vezetékeket úgy,mintha 8 lábú ic lenne, és ez ment az spi programozóba. 

Szoftver a PC-n:

A flashrom programot simán tárolóból telepitettem linux mint 21.3 alá:

 

apt install flashrom

 

ezután ellenőriztem hogy ismeri e ezt a chipet

 

flashrom -L | grep 25L12835F

Szerencsére igen:

Macronix MX25L12835F/ PREW 16384 SPI 


 

Ezután fogtam a panelt, és rácsiptettem a csipeszt, usb-n csatlakoztatam az égetőt a géphez, és linux konzol alatt inditottam a flashrom-ot így(fontos, hogy nem kell tápot adni az ap-nak).

flashrom -p ch341a_spi





Nagyon fontos a chip jelölt lába az 1.es láb.nem a fehér pötty, hanem az átellenes sarkán az a másik.

Na itt volt némi játék mire sikerült ráigazitanom a csipeszt a chip-re, de ha sikeres a dolog ez jött vissza:

 

flashrom v1.2 on Linux 5.15.0-176-generic (x86_64)

flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).

Found Macronix flash chip „MX25L12805D” (16384 kB, SPI) on ch341a_spi.

Found Macronix flash chip „MX25L12835F/MX25L12845E/MX25L12865E” (16384 kB, SPI) on ch341a_spi.

Multiple flash chip definitions match the detected chip(s): „MX25L12805D”, „MX25L12835F/MX25L12845E/MX25L12865E”

Please specify which chip definition to use with the -c <chipname> option.

Itt már sinen vagyunk, és jöhet a parancs amivel kiolvashatom:
 

flashrom -p ch341a_spi -c „MX25L12835F/MX25L12845E/MX25L12865E” -r dump.bin 

-ezt kétszer olvastam ki és hasonlítottam őket össze.
 

cmp dump.bin dump2.bin
 

ha minden rendben akkor egy üres prompt-ot kapsz.
Ezután itt volt az idő, hogy kiolvastam jó ap-ból a tartalmat. Ezt donor.bin és donor2.bin néven mentettem. 




Jöhet a két tartalom összefűzése:
feljebb mutattam a particios tábláját a jó ap-nak és ott látszik, hogy a flash elején lévő 0x60000 irom csak be, a többi marad. Erre a feladatra dd-t használtam:

dd if=donor.bin of=dump.bin bs=1 count=$((0x60000)) conv=notrunc

ezután írjuk vissza a chipre az image-t:
 

flashrom -p ch341a_spi -c „MX25L12835F/MX25L12845E/MX25L12865E” -w dump.bin


ha minden oké akkor lehet tápot adni a készüléknek, és ha jol csináltunk mindent a led szépen nekiáll villogni jelezvén, hogy boot-ol.
Igazábol miután feléled az ap rajta van a konfigja, és elkezdi azokat a ssid-ket sugározni amik rajta voltak. 
Elvileg visszahozva az életbe az ap.

Nekem az az érzésem, hogy az automata upgrade volt ami brickelte az ap-kat.
Mind ugyanabban az időben, autofirisités közben halt meg.

Vélemény, hozzászólás?

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük