This translation is older than the original page and might be outdated. See what has changed.

Guide de « débriquage » sous OpenWrt

Quand les gens disent qu'un routeur est briqué, ceci signifie qu'il ne fonctionne plus correctement et les raisons peuvent être multiples. En premier lieu, vous devriez vous détendre, essayer de comprendre et lire Agencement de la mémoire flash, "Le système de fichiers d'OpenWrt" et "La ligne de commande du chargeur d'amorçage" . Maintenant, selon ce qui, précisément, est dégradé, vous avez plusieurs possibilités :

  1. Si la partition JFFS2 seulement est corrompue, vous pouvez encore démarrer dans le → mode sans échec d'OpenWrt
  2. Si la partition SquashFS ou le Noyau sont corrompus, vous ne pouvez plus démarrer dans le mode sans échec. Mais vous avez encore un chargeur d'amorçage, c'est pourquoi vous devriez suivre la même procédure que lorsque vous avez installé OpenWrt la première fois via le chargeur d'amorçage.
  3. Si le chargeur_d_amorcage est corrompu, il ne vous reste que deux options :
    1. accéder à votre matériel via le port JTAG, ceci devrait vous permettre d'écrire dans la mémoire flash et restaurer de chargeur d'amorçage.
    2. ou dessouder le composant portant la mémoire flash , y connecter quelqu'appareil qui vous confère une possibilité d'écriture et restaurer le chargeur d'amorçage. Vous avez fait une sauvegarde, bien ?

Vous devez savoir souder, vous pouvez trouver de l'aide ici :

En ce qui concerne la bonne manière de récupérer un routeur briqué

boot_wait

La meilleure des choses simples à faire est de valider boot_wait, ce qui signifie que tout ce que vous avez à faire c'est de charger un nouveau firmware par TFTP. À une certaine époque, les instructions de réécriture incluaient une mise en œuvre de dépannage pour le firmware Linksys qui positionnait la variable boot~wait; avec le temps, Linksys (après plusieurs tentatives ratées) régla le bogue,mais les gens continuaient à écrire d'autres firmware avec pour seul but de positionner la variable boot_wait afin de pouvoir ensuite écrire OpenWrt. Comme c'était sans intérêt, nous avons changé les instructions pour indiquer que l'on pouvait réécrire OpenWrt en toute sécurité sans positionner la variable boot_wait.

JTAG

C'est quelque chose d'étonnamment utile pour récupérer de pratiquement n'importe quoi pourvu que ce ne soit pas une panne matérielle. Tandis que JTAG peut être utilisé pour surveiller la moindre instruction et enregistrer pendant le démarrage du système, le logiciel de récupération ne l'utilise que pour les accès DMA à la mémoire flash, en faisant en quelque sorte un mécanisme de récupération aveugle.

La plus grossière erreur que les gens semblent faire avec JTAG, c'est de “ tout effacer et recharger le CFE (Common Firmware Interface)”; ils ne peuvent soit trouver la bonne version du CFE après avoir effacé le routeur, ou ils réécrivent avec un CFE qui est incompatible avec leur routeur. Vous devriez toujours utiliser la version du CFE fournie avec votre routeur., plutôt que de tenter de la remplacer avec un CFE que vous trouvez au hasard sur Internet.

La deuxième erreur - embarqué avec le CFE, il y a un jeu de valeurs par défaut de NVRAM à utiliser si la partition NVRAM est absente. Ceci veut dire que dans la plupart des cas, vous pouvez effacer tout sauf le CFE et ça démarrera facilement, recréera NVRAM et commencera à attendre pour un firmware via FTP. Dans certains cas cependant, les valeurs par défaut embarquées avec le CFE (celui fournit avec le routeur) ne correspondent pas avec le matériel réel et le CFE ne parvient pas à démarrer. C'est pourquoi, nous avertissons de ne pas effacer NVRAM. Pour récupérer de cette situation, vous devez avoir, soit le contenu original de la NVRAM, soit une version de CFE avec les valeurs par défaut correctes.

Serial

Serial consoles are great, there's just one problem - the routers run on 3.3v and a normal PC serial port puts out +/-12v, easily frying a router. This means that a level shifter such as a max233 is required (free samples can be obtained from Texas Instruments or Maxim), and adding the ICs and caps required is beyond the ability of most users -- luckily there's a shortcut. Most cellphones are either USB or 3.3v serial, so the data cable for a 3.3v cellphone can be used to make an easy and professional looking serial console connection (e.g the DKU-5 Cable for Nokia handsets). You only need to identify and connect 4 wires (vcc, rx, tx, gnd) -- and if your cable uses a pl2303 you can skip the vcc connection.

Serial console allows you to interact with the CFE command line, watch the kernel boot and console access to linux. This is probably the only way you'll every get any meaningful feedback about the device boot up.

Arduino

If you have an Arduino board you can upload a sketch that will send the debrick commands via serial. An example that works for the TP-WR703N is available here: https://forum.openwrt.org/viewtopic.php?pid=191463. Note that the commands for your router could be different!

WIFI

If by chance the lan bridge is not working after flashing and the router is inaccessible, it might be worth a shot to use the serial instructions to add a serial port and configure Wifi. If ssh connection via Wifi is working a newer/bugfixed/stable image can be copied via scp and then installed via sysupgrade command.

LEDs

Most people assume the LEDs on the front are deterministic, and that by telling you which LEDs are lit you can instantly tell if the hardware is working or where it crashed in bootup. This unfortunately isn't the slightest bit true.

  1. Power LED. The biggest mistake people make here is “my power led is blinking, what does that mean?”. There's an assumption that if the LED is blinking there must be software turning the LED on and off, and that it must mean something. The blinking is actually done in hardware; software only as the ability to set the LED “on” or “blink” -- it defaults to blink on power up and isn't set to on until after the firmware boots. If the led is on then you know the firmware booted; blinking really doesn't tell you much.
  2. Switch LEDs. The second common mistake is “the switch still works”. Of course the switch still works, it's a separate piece of hardware and the LEDs are wired directly to it. The only useful bit of information you can get is “all the switch LEDs are lit”. When the switch chip is reset, all of the ports will light up (even if no devices are connected) for about a second; this happens at power up and again as the firmware boots and reprograms the switch. If they stay lit, you're either a moron for not noticing the ports are actually in use, or someone has broken/shorted the switch chip. You can also notice reboot loops by watching for the switch reset.
  3. Diag/DMZ LED. Controlled by OpenWrt (diag module) to indicate bootup.
  4. Wifi. Controlled by the wifi driver; trivia - the wifi driver can also reset the power led in certain situations.

Stupid things people do

Pin shorting

In the past we used to suggest that people shorted a few pins of the flash; when CFE booted and attempted to perform the CRC32 there would be a flash read error which would change the outcome of the CRC and the resulting failure would force CFE into recovery mode. It's a great trick, but over the years we've learned that people are idiots and will take that as an invitation to poke mangle and short just about every pin on the device based on some irrational belief that if they find the right pin everything will magically work again. You do not want someone paranoid at the thought of breaking the device scraping up every single electrical connection on the device -- it never ends well, and generally results in the flash chip or the router being damaged in the process.

- frying a chip (worst case) - lifting/breaking electrical connections - permanently shorting (best case)

The best case is that they simply bent a pin and you can easily bend it back - providing you can find it.

Depending on which pins are shorted/broken, it may be possible to access CFE but not to access the rest of the flash. Meaning CFE boots fine but can't read or write the firmware. This can be confirmed by JTAG.

Wrong CFE version - Loading the wrong CFE version can also lead to devices which boot into CFE but are unable to write to the flash, or are unable to initialize the networking.

And yes, there are actually a few obscure versions that require the firmware to be named “code.bin” or a specific port to be used. Unfortunately nobody can remember exactly which devices, leading to all sorts of superstition.

This article is based on: https://forum.openwrt.org/viewtopic.php?id=11304

by Vavasik

In this case, someone manage to wipe out the bootloader of his D-Link DIR-825.

The full originals by vavasik can be found at:

  1. Open the Router’s case
  2. Find an IC SPI Flash SPANSION S25FL064A (Package SO3 016 wide), it is located on the backside of the router PCB.
    1. There are some variations regarding the IC used by D-LINK. In my particular case, the IC is from a different player. It is a ST Microelectronics chip labeled 5P64V6P 7B469 VS, but the pin outs are exactly the same.
  3. To record to flash chip it is necessary to build a simple cable that is connected in one side, to PARALEL PORT of your computer, and on other side you have to SOLDERING THE WIRES DIRECTLY INTO IC PINS.
DB25 # PIN---------------RESISTOR---------------FLASH IC # PIN

7 ----------------------------[150Ω] ----------------------------- 7
10 ---------------------------[150Ω]------------------------------ 8
8 ----------------------------[150Ω]----------------------------- 16
9 ----------------------------[150Ω]----------------------------- 15
18 ---------------------------------------------------------------- 10 GND (or "GND" on JTAG pads)

|----------- {recommended cable length = 120 mm} ------------|

It is also necessary to provide some external power supply (during the flashing process the router’s power adapter connector should be NOT INSERTED). So, in my case I decided to use a simple 3 x AAA 1.2 Volt NiMH battery holder that I assembled together with the cable itself.

Since the batteries are placed in a serial arrange, the final voltage of the set is 3.6 Volt. 

FLASH IC # PIN--------------------BATTERY ARRAY--------------------FLASH IC # PIN

10 ----------------[ - 1.2 Volt +]----[ - 1.2 Volt +]----[ - 1.2 Volt +]--------------- 2
  1. 4 It is not necessary but it could prove useful, to be capable to follow the boot process through serial console. In order to achieve that it is recommended to install some connections pins into the empty board holes related to JP1 connector. You can use the pins from old computer parts.
DIR 825 SERIAL PINOUTS (connector JP1) is:

PIN 1 -> 3.3V (Pin 1 is the one close to a small switch and a LED indicator)
PIN 2 -> RX
PIN 3 -> TX
PIN 4 -> GND
  1. <5> Use a TTL to RS-232 cable to connect to serial console. A good, easy and cheap option is to buy a USB to Phone cable like the model CA-42. Here in Brazil this cable can be found for about US$ 3.00.

Since you have the cable all you have to do is to cut off the Phone connector side and to identify the GROUND; TX and RX wires. It is quite easy and the web is plenty of guides that teach how to do that.

Use a terminal emulator software (I like PuTTY) configured as follow:

Speed (baud) 115200 Data Bits 8 Stop Bits 1 Parity None Flow Control XON / XOFF

  • 6 Now that the LPT ADAPTER is done and its wires are soldering to the chip, you have to connect the other side to LPT interface of your computer and also to connect the 3,6V external battery array. You must see the light of some LEDs on board.
  • 7 So, if everything is done properly, download the software SPIPGMW at the following address: http://rayer.ic.cz/programm/programm.htm#SPIPGM Run it in a DOS session. It is good use the key “i” in order to check if the chip is correctly identified.

SPIPGMW.EXE /i

Program should show: 

SPI connected to LPT port at I / O base address: 378h, SCK pulse width: t 0us FlashROM JEDEC ID, type: 010216h Spansion S25FL064A (8MB)

In my particular case, the software shows the ST Microelectronics chip id. If you see “unknown chip” there is a problem with LPT cable connection, check connections and try again!

  • 8 - Download and save the appropriated image toDIR-825.
  • 9 - Before flashing the image it is necessary to allow recording in chip with the key “u” SPIPGMW.EXE /u
  • 10 – Prior to recording it is good to make a cleanup. Erase chip with the key “e” SPIPGMW.EXE /e
  • 11 – Now it is time to program chip with key “p” SPIPGMW.EXE /p file_name
  • 12 - Dump chip content to a file with key file “d” SPIPGMW.EXE /d filename_1
  • 13 - Check the success of recording operation by comparing recorded file and recently dumped file fc / b filename_1 filename_2. Files must have exactly the same content.
  • 14 - Disconnect LPT cable and external power supply, try to boot. Look at the serial console terminal program and follow the boot process. Luckily everything will work fine.
SPI FlashROM supported
ST Microelectronic:
M25P10 (128kB)
M25P20 (256kB)
M25P40 (512kB)
M25P80 (1MB)
M25P16 (2MB)
M25P32 (4MB)
M25P64 (8MB)
M25P128 (16MB)
This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2018/06/08 11:58
  • by tmomas