Forum Linux.embarqué Problème de transfert tftp par port série sur un routeur tp-link Archer C7 v4 briqué (resolu)

Posté par  . Licence CC By‑SA.
0
21
juin
2018

Bonjour
La situation:
Mon routeur tp-link archerC7-v4 openwrt/lede est (glorieusement) briqué par mes soins à la suite d'un flashage pour revenir au firmware d'usine.
Symptôme: aucune led s'allume, sauf celle du power qui s'éteint après 3 secondes.
J'ai essayé tous les reset possibles et imaginables glanés sur le net genre https://wiki.dd-wrt.com/wiki/index.php/Hard_reset_or_30/30/30
rien à faire. Il existe un espoir puisque le chargeur de boot ne semble pas mort.
Après identification des contacts, j'ai soudé sur le routeur 3 picots, tx rx gnd, pour communiquer avec un PC via le port série.
Branchement d'un adapteur ttl/usb PL2303HX USB entre le port série du routeur et le PC.
Vérification:

setserial -a /dev/ttyUSB0
/dev/ttyUSB0, Line 0, UART: 16654, Port: 0x0000, IRQ: 0
        Baud_base: 460800, close_delay: 0, divisor: 0
        closing_wait: infinte
        Flags: spd_normal

Sur le PC Arch Linux, pour info:
Pas de xinet installé mais un fichier /etc/xinet.d/tftp faisant partie du paquet 'inetutils' contenant:

service tftp
{
<------>socket_type<--->= dgram
<------>protocol<------>= udp
<------>wait<--><------>= yes
<------>user<--><------>= nobody
<------>server<><------>= /usr/sbin/tftpd
<------>server_args<--->= /var/tftpboot
<------>disable><------>= yes
}

Config adresse fixe ethernet du PC:

192.168.0.66 
255.255.255.0 
gateway 192.168.0.1

La conf du serveur tftpd:
/etc/conf.d/tftpd

TFTPD_ARGS="-l --secure /srv/tftp/"

Je lance tftpd:

systemctl start tftpd

Dans le répertoire /srv/tftp/ où réside le firmware officiel renommé en ArcherC7v4_tp_recovery.bin
Je lance:

tftp -l -v -m binary

tftp> status
Connected to 192.168.0.86.
Mode: octet Verbose: on Tracing: on Literal: on
Rexmt-interval: 1 seconds, Max-timeout: 280 seconds

tftp> put
(file) ArcherC7v4_tp_recovery.bin
putting ArcherC7v4_tp_recovery.bin to 192.168.0.86:ArcherC7v4_tp_recovery.bin [octet]
sent WRQ <file=ArcherC7v4_tp_recovery.bin, mode=octet>
sent WRQ <file=ArcherC7v4_tp_recovery.bin, mode=octet>
etc.....................................................

Je lance Screen

screen /dev/ttyUSB0 115200

Je démarre le routeur en maintenant la touche reset enfoncée.
Le transfert ne se fait pas. Extrait:

Loading: Tx Timed out
T Tx Timed out
T Tx Timed out
Tftp server tranfer fail!

Il faut savoir que sur un routeur tp-link openwrt, le fait de flasher le firmware d'origine conduit au briquage du routeur. Cela vient du fait que le firmware openwrt ne sait pas gérer la partie 'boot' du firmware tp-link officiel lors du flashage. Le firmware tp-link d'origine sait gérer la partie 'boot'. J'ai trouvé un script python ici

https://blog.flozz.fr/2013/07/14/debriquer-un-routeur-tp-link-tl-wr841nd-v84/

pour retirer la partie 'boot' du firmware.
(excellent tuto mais la méthode avec 'tpl' ne marche pas pour moi)
J'ai essayé les deux versions du firmware, firmware intégral avec 'boot' et firmware sans 'boot', j'obtiens la même erreur.
J'ai testé avec atftpd, idem.
J'ai testé avec Putty, idem.
A ce stade, à part une défaillance de l'adaptateur ttl/usb (comment le vérifier?), je ne vois pas d'où peut venir l'erreur.
Alors, si quelqu'un a une idée, merci…

Question: j'ai du mal à comprendre comment l'adresse de l'interface ethernet du PC peut être comprise par l'adaptateur ttl/usb
Comment ce périphérique série peut-il voir le réseau du PC?

La sortie intégrale de screen /dev/ttyUSB0 115200

U-Boot 1.1.4 (May 17 2017 - 17:19:54)

ap152 - Dragonfly 1.0

DRAM:  128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 395k for U-Boot at: 87f9c000
Reserving 16448k for malloc() at: 86f8c000
Reserving 44 Bytes for Board Info at: 86f8bfd4
Reserving 36 Bytes for Global Data at: 86f8bfb0
Reserving 128k for boot params() at: 86f6bfb0
Stack Pointer at: 86f6bf98
Now running in RAM - U-Boot at: 87f9c000
Flash Manuf Id 0xef, DeviceId0 0x40, DeviceId1 0x18
flash size 16MB, sector count = 256
Flash: 16 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   ath_gmac_enet_initialize...
No valid address in Flash. Using fixed address
ath_gmac_enet_initialize: reset mask:c02200
athr_mgmt_init ::done
Dragonfly  ----> S17 PHY *
athrs17_reg_init: complete
SGMII in forced mode
athr_gmac_sgmii_setup SGMII done
: cfg1 0x80000000 cfg2 0x7114
eth0: 00:03:7f:09:0b:ad
eth0 up
eth0
Setting 0x181162c0 to 0x50a02100
run command setenv serverip 192.168.0.66;setenv ipaddr 192.168.0.86
run command tftp 0x80060000 ArcherC7v4_tp_recovery.bin
Trying eth0
eth0 link down
FAIL
Using eth0 device
TFTP from server 192.168.0.66; our IP address is 192.168.0.86
Filename 'ArcherC7v4_tp_recovery.bin'.
Load address: 0x80060000
Loading: Tx Timed out
T Tx Timed out
T Tx Timed out
Tftp server tranfer fail!
tftpboot firmware failed, now start normally.
factory boot check integer ok.
factory boot load fs uboot len 131072 to addr 0x80010000.
Hit any key to stop autoboot:  0
## Starting application at 0x80010000 ...
U-Boot 1.1.4 (May 17 2017 - 17:19:43)

ap152 - Dragonfly 1.0

DRAM:  128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 122k for U-Boot at: 87fe0000
Reserving 16448k for malloc() at: 86fd0000
Reserving 44 Bytes for Board Info at: 86fcffd4
Reserving 36 Bytes for Global Data at: 86fcffb0
Reserving 128k for boot params() at: 86faffb0
Stack Pointer at: 86faff98
Now running in RAM - U-Boot at: 87fe0000
Flash Manuf Id 0xef, DeviceId0 0x40, DeviceId1 0x18
flash size 16MB, sector count = 256
Flash: 16 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   ath_gmac_enet_initialize...
No valid address in Flash. Using fixed address
ath_gmac_enet_initialize: reset mask:c02200
athr_mgmt_init ::done
Dragonfly  ----> S17 PHY *
athrs17_reg_init: complete
SGMII in forced mode
athr_gmac_sgmii_setup SGMII done
: cfg1 0x80000000 cfg2 0x7114
eth0: 00:03:7f:09:0b:ad
eth0 up
eth0
Setting 0x181162c0 to 0x50a02100
Hit any key to stop autoboot:  0
## Booting image at 9f040000 ...
Bad Magic Number
ath>
  • # tout melanger ?

    Posté par  . Évalué à 4.

    ton port USB/TTL te permet juste d'avoir une console sur ton routeur, et de lui envoyer des commandes, de voir ce qu'il s'y passe.

    le TFTP pour flasher le firmware va se lancer sur la carte reseau du routeur, peut-etre sur une seule des interfaces s'il y en a plusieurs.

    • soit il se lance en mode serveur et attent un push depuis un client (ton PC)
    • soit il se lance en mode client et il fait un appel dhcp/tftp sur le reseau et tente un pull d'un fichier qui se trouve sur le serveur tftp (ton PC)
    • [^] # |résolu] Re: tout melanger ?

      Posté par  . Évalué à 2.

      Bonjour
      Effectivement. Le problème était d'ailleurs clairement visible ici:
      Trying eth0
      eth0 link down
      FAIL
      Using eth0 device
      Je pensais stupidement que tout passait par le port série, et bien non…consternation, il manquait un cable ethernet branché sur le routeur… :)))
      Firmware chargé, routeur redémarré…
      Merci infiniment pour ta réponse qui m'a sorti de l'ornière. Bonne soirée.

      Poster une information ne signifie pas nécessairement adhésion

  • # Important à savoir

    Posté par  . Évalué à 1.

    Le flashage a réussi avec le firmware tp-link d'origine. Je n'ai pas testé le firmware amputé de la partie boot avec le script indiqué ci-dessus.

    Poster une information ne signifie pas nécessairement adhésion

  • # mais... c'est pas brické du tout!!! :-)

    Posté par  . Évalué à 2. Dernière modification le 21 juin 2018 à 20:57.

    Edit: à supprimer parce qu'en fait ton problème a été résolu dans le temps où j'écrivais ce post…

    • [^] # Re: mais... c'est pas brické du tout!!! :-)

      Posté par  . Évalué à 1.

      Oui, vite résolu sur linuxfr.org :) Pour être honnête, n'étant pas informaticien mais plutôt "bricoleur bidouilleur", ce débriquage m'a coûté préalablement un "certain temps". En attendant, j'ai hâte de rebriquer d'installer OpenWrt 18.06 qui devrait sortir bientôt , en espérant que l'Archer C7-v4 soit supporté…

      Poster une information ne signifie pas nécessairement adhésion

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.