Cerebro Seco

Se faciliter la vie informatique sans sacrifier ses principes!

Aller au contenu | Aller au menu | Aller à la recherche

Prolonger la vie de son WRT54GL - récupérer d'un crash de firmware, JTAG avec RPi, TFTP avec Mac

Au début de l'année, je parlais de méthodes pour récupérer d'un crash de firmware sur un WRT54GL, qui peut faire appel à divers types de câbles JTAG. Le JTAG, c'est cette antique et méconnue norme de test des circuits logiques, qui ne sert d'habitude qu'aux tests en usine, et toujours présente dans la plupart des appareils électroniques, dont notre bien-aimé Linksys WRT54GL. À noter que le JTAG est une méthode de récupération de dernier recours, quand toutes les autres ont échoué.

Difficulté: ésotérique.

Seulement voilà, utiliser le JTAG à partir d'un ordinateur demande un accès au port parallèle ou sériel, devenu particulièrement rare il y a une décennie. Bien sûr des câbles USB existent, mais leur prix a de quoi rebuter, surtout pour un usage très, très occasionnel. Puisque finalement, le JTAG n'est qu'une normalisation du "bit banging", ou transfert brut de données, il peut être implanté à faible coût à condition d'avoir les connecteurs nécessaires sur son ordinateur. Et qui dit "brut" en informatique dit souvent "de bas niveau". Passé de mode depuis longtemps en informatique, l'accès aux protocole de bas niveau est toujours présent, et même vanté sur le Raspberry Pi. Si vous cherchiez l'utilité de ce mystérieux connecteur hérissé du RPi

Fort heureusement et pour la moitié du prix d'un câble JTAG commercial et probablement inutile pour la plupart des gens, existe un obscur projet utilisant justement le port d'entrée-sortie générales (GPIO) du RPi. C'est open-source, expliqué ici, et hébergé par là.

Matériel

  • un Raspberry Pi faisant tourner un Linux quelconque
  • Huit fils avec connecteur simple femelle-femelle
  • Un Linksys WRT54GL, préalablement mort.
  • Une sauvegarde de votre fichier CFE, préférablement votre version, ou une recréée.

Méthode préférée: sauvegarde "normale" du bootloader

Dans Tomato, ça se trouve dans l'interface Web sous Administration > Debugging > Download CFE. L'avantage est que c'est votre propre copie du bootloader. On peut aussi le récupérer comme décrit ici. Les différents moyens de récupération ne fonctionnent pas tous cependant; la page a été écrite pour dd-wrt, et Tomato est légèrement différent. Sous Tomato, la méthode HTTP directe ne fonctionne pas, seulement la méthode à travers l'interface Web et celle faisant appel à la commande SSH.

Par l'interface web

Administration > Debugging > Download CFE

Captura_de_pantalla_2015-05-02_a_las_19.03.37.png

Par ligne de commande SSH

# dd if=/dev/mtd/0 of=/tmp/cfe.bin

Il faut ensuite extraire le fichier par un moyen ou un autre, soit en l'envoyant vers une clé USB montée et partagée en FTP comme je l'ai déjà décrit, soit configurer le FTP pour orienter vers le répertoire /tmp/. D'autres méthodes à base de scp existent, mais ne rentrent pas dans le cadre de cet article.

On compare sommairement les deux fichiers:

$ shasum cfe.bin
72a5aca00e85943e78b6af4c112754feb2600208  cfeWeb.bin
$ shasum cfeSSH.bin
72a5aca00e85943e78b6af4c112754feb2600208  cfeSSH.bin

Les checksum sont identiques, donc les deux fichiers obtenus sont les mêmes.

L'inconvénient, si ce CFE est corrompu, vous allez vous donner beaucoup de mal pour rien, ce qui m'amène à la méthode…

Second choix: à partir d'une sauvegarde "originelle" du bootloader

Le nécessaire se trouve dans cette archive, inspirée par l'excellent travail de VicTek,et contient le nécessaire pour récupérer d'un crash de firmware.

Restore_WRT54GL.zip

Il faut modifier les variables et0macaddr et il0macaddr pour qu'elles correspondent à celles de votre routeur! Ça passe par l'outil disponible ici, si vous n'en avez pas de sauvegarde. N'ayant pas eu grand succès avec cet outil, on peut utiliser le très bon imgtool_nvram de Jeremy Collake, qui hélas n'est compilé que pour Windows. Il faut donc sortir l'artillerie lourde avec VirtualBox, et une une installation de Windows XP (parce que c'est plus léger), et modifier en exécutant imgtool_nvram, en vue d'obtenir un CFE.bin qui soit conforme.

im.png

Il faudrait donc taper:

> imgtool_nvram.exe CFE.BIN et0macaddr=00:90:4d:83:00:01
> imgtool_nvram.exe CFE.BIN el0macaddr=00:90:4d:83:00:02

Un autre moyen un peu plus délicat mais présentant l'avantage de ne pas réclamer VirtualBox (utile pour les machines dotées de peu de RAM): utiliser HexFiend pour éditer directement le fichier CFE.BIN.

Captura_de_pantalla_2015-05-03_a_las_00.52.28.png

Troisième choix: directement dans le routeur

Une autre méthode est disponible le CFE est toujours intact, qu'en désespoir de cause vous avez réinstallé un CFE non personnalisé, et que le routeur peut être rejoint par la ligne de commande telnet ou SSH:

# nvram set et0macaddr=00:90:4d:83:00:01
# nvram set il0macaddr=00:90:4d:83:00:02
# nvram commit

La première adresse MAC est celle imprimée sur l'étiquette du routeur, la seconde est identique à la première, +1. Rappelez-vous que c'est compté en hexadécimal!

Étapes préparatoires

À titre indicatif, je n'ai pas voulu risquer un routeur qui fonctionne parfaitement.

  1. Connecter le Raspberry Pi et le Linksys comme indiqué
  2. Allumer le Linksys, puis le Raspberry Pi
  3. Télécharger et compiler le code source sur le Raspberry Pi. je ne reviendrai pas sur les moyens d'y accéder sans écran, ça a déjà été abordé. Exécuter.
$ cd ~
$ git clone git@github.com:oxplot/tjtag-pi.git
$ cd tjtag-pi
$ make tjtag
$ ./tjtag -probeonly

À cette étape tjtag devrait lire la mémoire du Linksys. Maintenant, les opérations suivantes peuvent être tentées pour récupérer du crash. Les autres détails sont disponibles sur GitHub, et la courte histoire mentionnant le pourquoi du comment sur le site de l'auteur, Mansour.

La récupération par JTAG comme telle

Je l'ai déjà dit, le JTAG est très lent. En général, on préfèrera restaurer le CFE et le contenu de la NVRAM avec le JTAG, et continuer avec le TFTP pour le reste du kernel.
  1. Essayer d'abord d'effacer le contenu de la NVRAM, ce qui est une source commune de problèmes:
    $ tjtag -erase:nvram
    
  2. Si ça ne fonctionne pas, effacer le kernel
    $ tjtag -erase:kernel 
    Puis flasher le kernet avec la méthode TFTP.
  3. Si ça ne fonctionne toujours pas, il peut être nécessaire d'effacer le CFE, et c'est là qu'il devient nécessaire d'avoir une copie du cfe.bin qui corresponde à ce routeur en particulier.
    $ tjtag -erase:cfe
    Et le réécrire avec
    $ tjtag -flash:cfe

    Dans ce dernier cas, le fichier CFE doit être dans le même répertoire que tjtag, et nommé exactement CFE.BIN.

La récupération du kernel par TFTP

C'est plus simple de relier le routeur au Mac qu'au Raspberry Pi pour cette tâche. Il faut disposer d'un firmware finissant en .bin, comme celui de dd-wrt version Mini, build 14896 et ici: dd-wrt.v24_mini_wrt54g.bin, build 14929, ou bien là: dd-wrt.v24_mini_wrt54g14929.bin, ou le firmware standard de Linksys: FW_WRT54GL_4.30.16.6_US_20130308_code.bin.

  1. Assigner manuellement une IP au Mac dans le même sous-réseau que le Linksys WRT54GL (Il se trouve habituellement au 192.168.1.1).
    Captura_de_pantalla_2015-01-09_a_las_01.41.02.png
  2. Relier le Mac au routeur sur un des ports LAN
  3. Rentrer par Telnet dans le routeur. Le mot de passe après un reset est "admin".
    $ Telnet 192.168.1.1
  4. "Casser" le kernel existant
    $ mtd erase linux
    $ reboot
  5. Envoyer des ping à partir du Mac de manière à faire répondre le routeur. S'il répond au moins quelques fois, c'est bon signe. S'il indique
    ttl=100
    encore mieux, c'est signe qu'il est prêt à recevoir un kernel. S'il répond avec un
    ttl=64
    c'est que le firmware précédent est toujours détecté, et qu'il faut recommencer l'étape 4.
    $ ping -t -w 2 192.168.1.1
  6. Débrancher le routeur
  7. Régler le serveur TFTP sur le Mac
    $ tftp 192.168.1.1
    > binary
    > rexmt 1
    > timeout 60
    > trace
  8. Brancher le routeur
  9. Immédiatement, entrer la commande
    > put firmwarefile.bin
  10. Patienter de trois à cinq minutes, le temps que l'interface Web devienne accessible au 192.168.1.1.
  11. Passer ensuite au firmware de Tomato de la manière habituelle, sans oublier les recommandations habituelles.
  12. Ne pas oublier que ça peut caler à n'importe quelle étape! Soyez patient. Le protocole TFTP est très sensible au minutage.

Autres liens

https://www.dd-wrt.com/phpBB2/viewtopic.php?t=47536
https://www.dd-wrt.com/phpBB2/viewtopic.php?t=52043

https://dd-wrt.com/wiki/index.php/Linksys_WRT54GL#Firmware

Comment faire la sauvegarde de son CFE, en détail

Méthode détaillée pour la récupération

La différence entre les différents builds de dd-wrt.

Le topic de dépannage fourre-tout.

Une collection de fichiers CFE.BIN, au cas où ce ne serait pas clair.