Huge mistake, sysupgraded with wrong binary Tp-link C50 on C5

Made a huge mistake och flashed sysupgrade 23.05 on 22.05 on my TP-link C5 v1.2 but with TP-Link C50 v1. I got an error about to force upgrade, and made sure I got the right binary and thought that it was beacuse v1.2 and not v1.
My device is unresponsive, I have not made anything yet to, my first thought is to do a hardware reset and if that doesn't work att serial tftd flash.
Whats the best thing to, or am I domed?

The most common method of debricking is with tftp. There is information here:
https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500#tftp_recovery_de-bricking

1 Like

Tried with tftp but with no success, running tcpdump on the host of tftp-server, I get octet timeout.
08:21:04.873433 IP (tos 0x0, ttl 255, id 2920, offset 0, flags [DF], proto UDP (17), length 73) 192.168.0.86.netview-aix-2 > MANAGEMENT-LAPTOP-FEDORA.tftp: TFTP, length 45, RRQ "ArcherC5v1_tp_recovery.bin" octet timeout 3

I have tried from another PC and it downloads the requested file
08:11:30.325160 IP (tos 0x0, ttl 64, id 57434, offset 0, flags [DF], proto UDP (17), length 66) 192.168.0.100.37600 > MANAGEMENT-LAPTOP-FEDORA.tftp: TFTP, length 38, RRQ "ArcherC5v1_tp_recovery.bin" netascii

Any suggestions on how to move forward?

You usually need to specify binary (bin) mode. Did you do that?

Do you mean to set the server in binary mode?
I could not find tftp-hpa on Fedora so I followed this guide https://gist.github.com/shamil/d2fb2bfa92b769c17df84706904d9ee7

Yes. You need to set the transfer mode to binary.

On a Mac, a tftp server is already built in. You would simply type binary on the command line once in the tftp environment.

I don't know about the tftp server you've used, though.

Typically, if you do not specify binary, the system will send ASCII.

As of my understanding it is the client setting the ascii/binary-mode. The client in this case is the Archer C5 and how this device´s tftp-client sets up the connection I cannot configure.
I will try another tftp-server on ubuntu in the weekend ( https://openwrt.org/docs/guide-user/installation/generic.flashing.tftp.easy-ubuntu ) to verify.
I don´t think binary is the problem, could it be that the device does not have enough space in the filesystem?

Tried with my PC to connect again to the tftp-server, this time I set the mode in the client to binary (first time it transfered the file with ascii). Output from tcpdump on server is
09:55:53.521403 IP (tos 0x0, ttl 64, id 1139, offset 0, flags [DF], proto UDP (17), length 63) 192.168.0.100.45740 > MANAGEMENT-LAPTOP-FEDORA.tftp: TFTP, length 35, RRQ "ArcherC5v1_tp_recovery.bin" octet
According to the log, it seems like the Archer C5 is trying to transfer the file in binary mode (octet) but gets a timeout.