I am attempting to recover a TP-Link Archer C7 using the Serial to USB connection.
I purchased this router used and was unable to access the Web Interface initially.
My first attempt was to use the TFTP method without success (resulted in bootloop).
When that failed I resorted to the Serial to USB method which appeared to be working until I powered up the router with PuTTY open and after a short initial burst there seems to be no real communication between the router and my computer.
I will attempt to attach a screenshot, but as I am new to this forum I may not get it right.
Any help will be appreciated.
I am not network savvy, but will answer any questions as well as I can.
My computer's OS is Windows 10, Version 1909.
I will be off the grid shortly, but will answer any inquiries upon my return in a few hours.
I am attempting to recover a TP-Link Archer C7 using the Serial to USB connection.
First of all, please avoid screenshots, if all you want to show is effectively a wall of text output - just copy and paste from your PuTTY window into a code box. Text is easier to read (think mobile devices with vertical screens), without having to resize an image, additionally the error messages can be indexed by your favourite search engine.
Let's start with the good news, you have a stable serial connection and have attached to the archer's serial console (that doesn't quite confirm that you can also write to this console yet, but at least part of the basics are working).
Now to the bad news, if that output really is everything you - halting after that line and not going further, you've damaged to bootloader (u-boot), at that point you haven't loaded enough of u-boot for a potential recovery (it's interesting though that you even get that far) - rendering the serial console based recovery mechanisms moot - and chances are, given you have already clobbered those portions of the flash, that you also overwrote the irretrievable wireless calibration data…
Should you decide to go further, the next step would be desoldering the spi-nor flash, rewriting it externally (backups first!) with the help of an spi-nor writer, soldering it back into the board - and hoping that the wireless calibration data is still intact (furthermore you'd need to recreate the appended ubootenv as part of uboot with your MAC addresses, etc.). Chances for successful recovery of wired-only operations should be good (if you know what you're doing), chances of successfully recovering wireless functionality would be less likely.
Please don't blindly try random things without really understanding what you're doing and why. What you got initially could have been recovered quite easily and with a high success rate, but your early recovery attempts made the situation much, much worse - to the extent that I'd consider this device to be a write-off.
Thank-you for your reply.
As I indicated in my post, I purchased this router used and was unable to access the Web Interface initially.
You said, *"...*you've damaged to bootloader (u-boot)...and chances are, given you have already clobbered those portions of the flash, that you also overwrote the irretrievable wireless calibration data…"
Not disputing any of that, but knowing what little I did do is it likely that "I" did the damage or more likely that I received it that way?
When a factory "Reset" did not work, I spent 2-3 hours online with TP-Link Technical Support and they concluded that if the router was still under Warranty (Serial Number confirmed it was not) they would replace it.
From there I went the TFTP route with the result that I referenced and of course as a last resort I attempted the recovery via. the Serial to USB.
I won't be pursuing this any further as I don't need the router (don't possess the knowledge/skills to do so either) and the Seller will not be returning my purchase price in any event (the primary reason I pursued it this far and I am DYI at some level).
Going somewhat full circle my big question is, is anything that "I" attempted the most likely explanation for the router's failure?
Again, your reply and input is very much appreciated.
That is not necessarily a problem.
- it might be that a firmware without webinterface was installed (e.g. an OpenWrt snapshot, which comes without luci preinstalled), ssh (and telnet, in case of really ancient firmwares) would have been the next step of testing, followed by attempting a factory reset (using the reset button).
- it might have been that the firmware was shot for one reason or another, which would have still left you the option of using push-button tftp recovery or serial assisted recovering (tftpboot of an initramfs image)
Obviously neither of these situations would have been ideal, but they would have been recoverable.
Believing your screenshot from the initial post shows the whole picture, namely that booting stops right at that line and sits there forever (respectively the h/w watchdog kicking in and rebooting after a while, always stopping at
ath_ddr_initial_config(211): (32bit) ddr1 init again), indicates that at least now, the bootloader is damaged and can't get to the point of interacting with it, nor being able to invoke push-button tftp recovery. This indicates that all 'normal' recovery method an (advanced-) enduser could do are no longer available (soldering && external flashing required).
In your original post, you mentioned:
To me, this reads as if:
- you've tried push-button tftp recovery 'blindly' (without serial console attached)
- the bootloader successfully fetched the factory/ OEM image image you provided from the tftp server and then did something with it (presumably attempted to flash it), depending on the log-level you enabled for this attempt this should have registered in the tftpd log (syslog) or the transfer should have been visible with wireshark
- ergo, at this point the bootloader was still 'intact' to the extent of starting the push-button tftp recovery procedure
- after this failed attempt, the router now behaves differently and doesn't even get as far as accepting a factory image offered from your tftpd.
- this change in behaviour "(resulted in bootloop)" (I read this as, it didn't bootloop before) indicates that your attempt of push-button tftp recovery 'succeeded' in flashing 'something' to the spi-nor flash, just that this something is even more broken than the status quo ante.
If the assumptions above are correct, this initial push-button tftp recovery attempt overwrote (at least-) parts of the installed bootloader with random garbage - and probably also beyond the end of the firmware partition, into the (irrecoverable) wireless calibration data that's stored in the last 64 KB of your flash chip, immediately behind the firmware (kernel+rootfs+overlay). This last bit regarding the potentially clobbered wireless calibration data (permanently breaking wireless connectivity) is admittedly pure speculation at this point (as you can't get to the point of confirming this anymore), but it usually comes hand in hand with the former - if something 'wrong' (too large) was attempted to be written to the flash.
What would be interesting as a post mortem, would be inspecting what exactly you tried to upload (well, technically download from the bootloader from your local tftpd) to the router (
ArcherC7v?_tp_recovery.bin) - it probably isn't what should have been provided (again, I'm not going to give advice here, as TP-Link has experimented just too much in this regard recently).
I'm a strong proponent of escalating recovery methods slowly, from mild to more invasive, e.g.:
- access attempts via webinterface
- access attempts via ssh/ telnet
- factory reset (reset button)
- tftp recovery (with a known-good image!)
- external spi-nor flashing (to be honest, unless I'm very sure what happened, how I got into this situation and with a good flash backup of my own device, I wouldn't go this far)
rather than taking the heavy machinery first.
TP-Link has 'experimented' with different firmware formats in recent times, so what exact firmware format is necessary (bootloader cut off, not cut off, something different) depends a bit on device and firmware version, so I'll refrain from giving advice here (I know their old devices, which required cutting off the prepended bootloader and its header - I've skipped purchasing their newer devices that need different procedures, so I didn't follow up with changing requirements - and you didn't mention the h/w revision in the first place).
Thank-you for a detailed, considered reply.
Regrettably I don't know enough to follow everything presented, but I feel like I understand in part.
You said, *"*ssh (and telnet, in case of really ancient firmwares) would have been the next step of testing." I have no idea what that is and I am not asking for an explanation. You have already gone above and beyond.
Where you said *"*I read this as, it didn't bootloop before," while I can't be sure or even attempt to explain it, I had the impression the router was in some form of "bootloop" from the very beginning.
You said "What would be interesting as a post mortem, would be inspecting what exactly you tried to upload (well, technically download from the bootloader from your local tftpd) to the router (
ArcherC7v?_tp_recovery.bin**) - it probably isn't what should have been provided."
Yes, a post mortem would be interesting. While it does not answer your question, I was working with firmware obtained from T-P Link for the Archer C7 Ver.2. Three firmware publications were offered and while it may have meant nothing it struck me as odd that the "format" (for lack of a better term) was similar for the 2016/2017 iteration, but different for 2018.
When you say "you didn't mention the h/w revision in the first place" I would have to say I don't know what that has reference to. I only understand the hardware model/version.
Sorry to raise more questions, but I cannot help but to try and relate your information to my inadequate understanding and experience.
Google has helped this DIY guy to do things that otherwise would have not been possible, but obviously it cannot be expected to be an "end all."
Thanks again for the courtesy of your reply and your time,
PuTTY, the tool you've been using to connect to the serial console of your router is more commonly used for ssh (or telnet). It gives you command line (shell) access to your router over the network, as mentioned before, e.g. snapshot builds of OpenWrt don't have the webinterface (LuCI) preinstalled and only allow access via:
The TP-Link Archer c7, h/w rev v2 follows the old style of TP-Link firmware formats, so the
ArcherC7v2_tp_recovery.bin image should have been uploaded without bootloader in front of the image, see https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500#return_to_factory_firmware for details. To summarize this quickly (and very roughly), if the size of your
ArcherC7v2_tp_recovery.bin isn't 100% identical to that of the corresponding OpenWrt factory image for your device, there is something wrong (cut at the wrong offsets or not cut at all, with the bootloader in front).
TP-Link has re-used the model name "Archer c7" for 5 different hardware revisions so far:
among these hardware variants, which differ quite considerably, only v4 and v5 are largely identical - all others need their own dedicated (actually different) firmware.
You of course piqued my curiosity with this last reply, so perhaps you are willing to go further with me.
Your protocol for escalating recovery methods:
access attempts via webinterface
access attempts via ssh/ telnet
factory reset (reset button)
tftp recovery (with a known-good image!)
external spi-nor flashing (to be honest, unless I'm very sure what happened, how I got into this situation and with a good flash backup of my own device, I wouldn't go this far)
Do I have this right; when I was unable to access the webinterface I went to PuTTY (ssh/telnet ), but only after trying to re-flash the firmware with TFTP.
And of course before any of that I had attempted multiple “Factory Resets” which in your protocol comes after “access attempts via ssh/ telnet.” (In addition to the “Factory Resets,” a “30/30/30” had been performed raising the question, are the Resets destructive?). In addition to this being out of sequence with your recovery method, perhaps this is where the damage was done?
Regarding the “firmware formats,” I was working with the following from T-P Links Support Download site:
(2016) - ArcherC7v2_en_us_3_15_1_up_boot(160719).bin
(2017) - ArcherC7v2_en_us_3_15_2_up_boot(170525).bin
(2018) - ArcherC7v2_en_us_180114.bin
which I renamed “ArcherC7v2_tp_recovery.bin” for recovery purposes. Not sure, but I probably used the 2018 iteration first, but before it was all done I had tried all three.
When the above did not work with the TFTP method, I moved on to the Serial to USB with the intention to flash the router with the firmware version of OpenWRT (openwrt-19.07.7-ath79-generic-tplink_archer-c7-v2-squashfs-factory.bin), but as we both know I never made it that far.