Hello, and thanks for reading this.

I just bought a brand new TP-Link Archer C5, I Installed OpenWRT via stock firmware webpage (browse, .bin select), and it just worked fine.

I had some trouble configuring the WAN in OpenWRT (it's my first time with it), so I decided to go back to stock firmware while I read more documentation.

I downloaded the .bin from the TP-LINK webpage for my model/hw, and I used this method using the OpenWRT CLI:

http://wiki.openwrt.org/doc/howto/generic.uninstall

All went fine in the console (no errors), the last message I saw was "Rebooting..."

Now I cannot ssh, telnet... Recovery mode doesn't work... It's bricked.

SYS LED is always on.
LAN LEDS are all always blinking. My linux goes crazy, it's detecting that i'm enabling/disabling the LAN in an endless cycle.

What can I do?

I was thinking to try the TFTP (from Archer C7) recovery method, using this:

https://www.mikepalmer.net/tp-link-arch … -recovery/

But I'm having some trouble to set up the server un my linux machine (it always say "transfer timed out").

Any other solutions?

Any help would be appreciated.

Thanks in advance.

P.S. Excuse my english, it isn't my native language, I hope it's enough to be understood.

(Last edited by sh4 on 3 Jan 2015, 02:58)

Regarding original bricking, did you read the device-specific advice about your device:
http://wiki.openwrt.org/toh/tp-link/tl- … y_firmware
You might have needed to cut away the bootloader part from the image before flashing.

Also the TFTP recovery process seems to depend on the exact firmware with which the router came originally (or on the bootloader that has been updated in a later OEM firmware upgrade). Both the correct filename and the correct IP may change.
http://wiki.openwrt.org/toh/tp-link/tl- … p_recovery

Hi,

first of all, don't worry, it's very unlikely that you actually bricked your router. Even if you flash a non-functional or damaged image, you still have at least two options for recovery (usually serial access and JTAG). With all the required tools available it's usually easy to bring a router back to life after a failed firmware upgrade.

It's very likely that the bootloader is still operational but it cannot load the stock kernel image you flashed for some reason (for example, the image you flashed contains some header which needs to be removed before writing to flash).

Also, you might be using the wrong IP subnet, check this out:

http://wiki.openwrt.org/toh/tp-link/tl- … p_recovery

The interesting part is: "Firmware 3.14.1 updates the bootloader to use an IP address of 192.168.0.66 and look for a file named ArcherC7v3_tp_recovery.bin even on hardware v2 units"

Have you tried using both 192.168.1.x and 192.168.0.x subnets?

For the TFTP server, depending on the actual implementation, you might need to enable the service within xinetd to run it and copy the image to the directory /tftpboot so that the router can fetch it. In some cases, global read access might be necessary in order to successfully serve the image to the client (simply set 777 rights on the directory and the file itself to ensure access).

On CentOS, tftpd's configuration is in file /etc/xinetd.d/tftp but it should be similar for other distros, too.

To enable the service, you need to change the line "disable = yes" to "disable = no", otherwise xinetd will not start the daemon and your router won't be able to fetch the image.

As usual, make sure to start or restart the xinetd service once you have tftpd enabled.

Finally, if you have a firewall on your PC, ensure that it enables access to UDP port 69 from the local subnet.

(Last edited by geryhun on 2 Jan 2015, 11:41)

First of all thank you both for your responses, they helped a lot.

I "unbricked" my unit succesfully with the TFTP recovery method, so I can confirm it works on Archer C5 v1.20

Not sure which file is the correct (in naming terms) I copied the same file (Archer C5 Bin) covering multiple combinations and put them into the tftp server directory:

sh4@notezator:/tftpboot$ ls
ArcherC5v120_tp_recovery.bin  ArcherC5v3_tp_recovery.bin
ArcherC5v12_tp_recovery.bin   ArcherC7v2_tp_recovery.bin
ArcherC5v1_tp_recovery.bin    ArcherC7v3_tp_recovery.bin
ArcherC5v2_tp_recovery.bin

The IP I used was: 192.168.0.66
I Rebooted the router with the WPS button "clicked" like here:

https://www.mikepalmer.net/tp-link-arch … -recovery/

And the leds behaviour changed. After a couple of minutes, I changed the IP back to 192.168.1.2 (gw 192.168.1.1) and I could be able to telnet into the router!

Then I went back to factory defaults using:

root@(none):/# mount_root
jffs2 is ready
jffs2 is ready
switching to overlay
root@(none):/# mtd -r erase rootfs_data
Unlocking rootfs_data ...
Erasing rootfs_data ...
Rebooting ...

And Bang! I can login via web now .

Now I will have to do some research to configure the WAN. I might need some help on this, but I am very happy, my router is alive!

SOLVED!

P.S: Excuse my poor english.

(Last edited by sh4 on 3 Jan 2015, 02:54)

Hi..
I'm in totally same case with sh4 except my router is Archer C7.
But, tftp recovery doesn't work for me.

I've checked uploading ArcherC7v2_tp_recovery.bin firmware by tftp.
tftp server(192.168.1.66), router in recovey mode(192.168.1.68)

but, nothing is changed.
Uploding firmware, reboot, then
All LEDs are blinking endlessly.

I've tried with ddwrt firmware, openwrt firmware(BB) and tp-link firmware(2014/09 released)..

Is any other way to out of this..?
Or is there something mistakes?
Thanks in advance.

(Last edited by mashedon on 21 Jan 2015, 23:49)

I got the same problem as user sh4.
TFTP Recovery works for me, but when the TFTP server is uploading the firmware file, it stops at some moment because the router constantly reboots itself. (All LAN Leds Blinking). Who can help me please??

@mashedon sorry for the late response, did you try also with 192.168.0.66? More name combinations? I tried a lot in my Archer C5 to be sure that wasn't the problem.

"The serial-less TFTP recovery method for the TP-Link TL-WDR4300 also works for the Archer C7 (confirmed only on v2). For firmware revisions before 3.14.1 (140929), the router uses an IP address of 192.168.1.66 and looks for a file named ArcherC7v2_tp_recovery.bin. Firmware 3.14.1 updates the bootloader to use an IP address of 192.168.0.66 and look for a file named ArcherC7v3_tp_recovery.bin even on hardware v2 units. "

@JurreFCT Did you tried to reboot with the WPS button click as I did? Even if the router didn't work after doing the TFTP recovery, the lights behaviour changed (the blinking wasn't the same), and I was able to telnet into the router after changing the static gateway to 192.168.1.1.

To both:

Are you sure you have the TFTP server up and working with the image in the /tftpboot folder (with the right name)?

You have to set the PC to the correct static IP/GW.

I use debian everyway but not sure why, the TFTP server wasn't working with it, so I did with an ubuntu fresh untouched Live USB and it worked flawlessly!

http://askubuntu.com/questions/201505/h … ftp-server

Follow a guide, and be sure to test the TFTP server with possitive results (transferring a testing text file and being sure it transfers the file with its content, not only creating an empty file), maybe the problem is in your TFTP server, or is a folder permission issue, etc...

You have to be sure you discarded any problem in your TFTP server/computer configuration.

Let my now if you need additional help.

David.

(Last edited by sh4 on 21 Feb 2015, 11:56)

Same issue here.

@sh4 - you're missing their description of the issue - tftp starts transmitting, then fails in a reboot loop.  (This rules out wrong ip, wrong file, bad file placement, etc)

I've recovered multiple routers, including the same C7 that's now bricked, using tftpd and the recovery file - it's quite easy.  Unfortunately, once you get into a loop like this - you can't get out.

(Last edited by hancox on 5 Apr 2015, 15:23)

@hancox Not sure if you didn't read the whole thread or simply you didn't understood me. Or maybe I didn't understood them (you) at all.

I was also in a reboot loop and I could unbrick my unit successfully with the TFTP recovery method (at least with my C5, not sure about C7) I explained in my previous posts.

The main idea of the my previous post, based on my own experience was to point out the importance of testing and to be 100% sure that the TFTP server is working ok by doing some file transfer tests. (It could be a permission issue, or whatever). I spent a couple of days trying it without success and in my case the problem was that, the TFTP server wasn't working correctly (although I thought it was ok).

Maybe it's a timing issue, or maybe we have different kind of bricks. My brick (as I explain in my first post) occurred when I tried to go back to stock firmware from OpenWRT.

Hope this helps.

(Last edited by sh4 on 6 Apr 2015, 19:59)

For anyone landing here and is confronted with the same issue:

My Archer C5 ( Hardware rev. 1.20 ) looked for "ArcherC5v1_tp_recovery.bin" at 192.168.0.66 .
The custom built OpenWRT-factory image worked fine, and don't be surprised if it takes a little bit longer than your usual flash process.

The issue I seem to have is that the router doesn't like the checksum of my image... I've tried multiple types. Does anyone have a suggestion?

Finding which address and image name the router in recovery mode is looking for:

myhost% sudo tcpdump -ni enp0s25 arp -vv
tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes

18:01:59.778046 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.66 tell 192.168.1.86, length 46
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel


myhost% sudo ip addr add 192.168.1.66/24 dev enp0s25

myhost% sudo tcpdump -npi enp0s25 udp -vv
tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes

18:04:50.693120 IP (tos 0x0, ttl 255, id 304, offset 0, flags [DF], proto UDP (17), length 73)
    192.168.1.86.1688 > 192.168.1.66.69: [no cksum]  45 RRQ "ArcherC7v2_tp_recovery.bin" octet timeout 5
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

Trying to upload the binary over tftp while sniffing with tcpdump at the same time:

myhost% atftp --verbose --trace --put --local-file ArcherC7v2_tp_recovery.bin 192.168.1.86
Verbose mode on.
Trace mode on.
sent WRQ <file: ArcherC7v2_tp_recovery.bin, mode: octet <>>
timeout: retrying...
sent WRQ <file: ArcherC7v2_tp_recovery.bin, mode: octet <>>
timeout: retrying...
sent WRQ <file: ArcherC7v2_tp_recovery.bin, mode: octet <>>
timeout: retrying...
sent WRQ <file: ArcherC7v2_tp_recovery.bin, mode: octet <>>
timeout: retrying...
sent WRQ <file: ArcherC7v2_tp_recovery.bin, mode: octet <>>
timeout: retrying...
sent WRQ <file: ArcherC7v2_tp_recovery.bin, mode: octet <>>
timeout: retrying...
tftp: aborting

Here's the sniffer:

myhost% sudo tcpdump -npi enp0s25 udp -vv
tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes

18:13:44.681473 IP (tos 0x0, ttl 64, id 3685, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.66.44325 > 192.168.1.86.69: [bad udp cksum 0x8425 -> 0x1adc!]  35 WRQ "ArcherC7v2_tp_recovery.bin" octet
18:13:49.686646 IP (tos 0x0, ttl 64, id 4470, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.66.44325 > 192.168.1.86.69: [bad udp cksum 0x8425 -> 0x1adc!]  35 WRQ "ArcherC7v2_tp_recovery.bin" octet
18:13:50.897832 IP (tos 0x0, ttl 255, id 315, offset 0, flags [DF], proto UDP (17), length 73)
    192.168.1.86.3359 > 192.168.1.66.69: [no cksum]  45 RRQ "ArcherC7v2_tp_recovery.bin" octet timeout 5
18:13:54.691829 IP (tos 0x0, ttl 64, id 4741, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.66.44325 > 192.168.1.86.69: [bad udp cksum 0x8425 -> 0x1adc!]  35 WRQ "ArcherC7v2_tp_recovery.bin" octet
<snipped...>
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

What's it want? A truncated image? People here seem to be having success with the regular openwrt images.

EDIT: the bad checksum was a red herring, probably due to packet shaping on the hardware or something. I ended up serving the file with tftpd instead of trying to 'put' it with a client. Worked fine.

(Last edited by badhat101 on 22 Jul 2015, 03:23)

Hey Guys -

Which exact firmware eventually worked for you guys when restoring over TFTP?

I see you say OpenWRT Stock, but don't know which specific one that is as the ones I've tried aren't working for me.

I'm seemingly having the exact same issue with my Archer C5 1.20 which I just posted about (link below)
https://forum.openwrt.org/viewtopic.php … 30#p287830

The TFTP method seems to work for me, but once the FW's transferred, the boot loop stops and LAN Port 1 (where cable's attached) lights up showing connected, but I can't communicate with the router at all via telnet, HTTP, or even ping on the 1 or 0 subnet.  I think I may be using the wrong firmware even though I've tried many.  Did you have the same issues?

Thanks

(Last edited by BzowK on 16 Aug 2015, 19:52)

Hi everybody,

I'm afraid I'm in a similar situation. 

I've got an Archer C7 v2.0 on which I had successfully been running dd-wrt.  For various reasons, I wanted to switch to OpenWRT.  I read a lot of pages on the Net and forum posts and performed what I thought was the correct procedure.  Apparently, it was not.  Most likely I didn't properly strip off the correct part/amount of the image file I tried to flash.  Anyway, now I'm in the lovely boot loop.  No!

The symptoms:
LEDs blink in a pattern with a roughly six second period.  Kernel messages about the eth0 interface going down and back up (see messages below) seem to indicate that the boot loop has a period of 11-12 seconds.

To sum up where I'm at now:

- Whatever is running at boot time, the OpenWRT failsafe mode is *not* working

- TFTP *is* working:
Following the TFTP unbricking directions on the wiki page for the Archer hardware, I set my PC to IP 192.168.0.66.  I'm using Debian, so I installed the "atftpd" package for the TFTP daemon and "tftp" for the client.
By default, it serves files out of "/srv/tftp" so I put into that directory an image file named "ArcherC7v2_tp_recovery.bin".  I manually tested getting the file from the TFTP server and that worked okay.
I then, plugged in the router, powered it on, and held down the WPS button until the transfer began.  I could see the I/O spike on the network I/O graph widget I have running on my desktop.  I also see in syslog the following lines:

Nov 20 17:00:34 Redtail atftpd[31449]: Advanced Trivial FTP server started (0.7)
Nov 20 17:00:34 Redtail atftpd[31449]: Serving ArcherC7v2_tp_recovery.bin to 192.168.0.86:1106
Nov 20 17:00:36 Redtail kernel: [385927.863533] r8169 0000:02:00.0 eth0: link down
Nov 20 17:00:38 Redtail kernel: [385930.315291] r8169 0000:02:00.0 eth0: link up
Nov 20 17:00:39 Redtail kernel: [385931.041901] r8169 0000:02:00.0 eth0: link down

So, it appears that the router *is* fetching the file, but it immediately resumes the endless boot loop.  From reading other messages in this thread, I suspect that if I were to plug in a serial console I would see the LZMA decompression error message mentioned by others.

I've tried *many* different image files, and have tried stripping off various lengths at the beginning according to different forum posts and wiki pages.  So far, none of them have worked.  The images tried include OpenWRT CC (both factory and sysupgrade), the dd-wrt firmware it used to be running, and the most recent firmware available from TP-Link's website.

What am I doing wrong?  I was initially really happy when I got the TFTP transfer to function as it meant that I could still communicate with the router.  That bloom has since faded, however, as I have been unable to get past this point.  Any help would be greatly appreciated.

The same issue.

Tried to unbrick Archer C7 via tftp.

It successfully fetches recovery file ArcherC7v2_tp_recovery.bin (original firmware stripped and openwrt factory bin) but after that nothing happens.

No reboot, nothing changed in blink pattern, nothing.

Can somebody connect to it via serial and look what is going on ?

@BzowK

I recovered it with Barrier Breaker for my C5 v1.20.

@Others:

Cannot help more, sorry.

In my case it was the tftp server, my advice is to ensure 100% with other files (a text file or whatever and see it the data isn't corrupted during the transfer) it's working OK, it's easy to have any permission issue or bad configuration in that end.

Mine is now in perfect condition, I event updated it to chaos calmer.

Good luck.

@sh4

Probably with C5 it is working, but I suspect that for C7 - doesn't.

Tried different files: original stripped, chaos chalmer factory bin, barrier breaker factory bin.

The same situation for all files. So I think that something bad happens AFTER file is fetched via tftp.

But I cannot check what is going on because no serial adapter .

Maybe other guys can look into serial console and find out what is going on next.

@sir_j Ouch!

I hope you could find a solution for that C7.

I suppose that our issues are internally different, because I copied the TFTP recovery method from the C7 guide (and worked also with my C5).

https://www.mikepalmer.net/tp-link-arch … -recovery/
https://wiki.openwrt.org/toh/tp-link/tl-wdr7500

I just could wish you good luck, and to post back the results if you find a solution so the other users can benefit from it.

@sh4

I've tried the both manuals. Still no luck.

The problem is I don't have a serial adapter so I don't know what happens after recovery file is uploaded via tftp method.

That's why I'm asking for help from someone who HAVE serial adapter and can look what is going on after recovery file is uploaded.

@sir_j  hope someone has, I have no problems at the moment but I am also interested, because I could be im the same place tomorrow.

Don't give up!

To those who are still struggling at this moment, here provides an extra information for reference.

First thing first my PC is running Windows 10 64-bit.

I reverted back to stock this evening when my bandwidth was upgraded to 1000Mbps. Without any knowledge of flashing back to stock, I just flash straight through Web UI. It shows successful message in console.

However after 2 hours of waiting, the LED interface was still repeating the same pattern and suspected the soft-brick.  I found every article about de-brick a C5 v1.2 but no avail. I tried changing IP address 192.168.0.66 and 192.168.1.66 back and forth; set my tftp with different combinations and it stills show no sign of connection. I could see the tftp was up and ready as indicated by the LED indicator (when WPS/Reset button was hold for ~5seconds starting from powering on the router). At some point of time I just want to open the case and use serial connector to fix it all.

It turned out that it was the network adaptor problem. In order to search the solution, I USB-tethered all the time (that's one adaptor). There are some other adaptors (e.g. VMWare virtual adaptors in my case) in the list. After disabling all the unnecessary adaptors, and voila my tftp server detected the request from 192.168.0.68 and LED indicator show something new. After a minute or so, good old login page is accessible.

tl;dr Network adapter setting may be the reason that TFTP is not working. Try disabling all unnecessary network adaptors and isolating the one that matters.

Cheers,
MM