OpenWrt Forum Archive

Topic: TPLink US Firmware Reflash Solution

The content of this topic has been archived between 26 Oct 2016 and 5 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I solder serial interface and successfully flash my router via serial console

https://i.ytimg.com/vi/hDO0ya9tJCw/hqdefault.jpghttps://www.youtube.com/watch?v=hDO0ya9tJCw

(Last edited by chiakhoavang.vn on 6 May 2016, 07:53)

BrainSlayer wrote:
anarchy99 wrote:

actually both v1 and v2 are vxworks based, but v2 does not accept uploaded microredboot...

did someone notice that i wrote the microredboot, but this russian site offers only encrypted files which can only be used by that tool. maybe i should write my own open solution, but i have not the required hardeware for testing

Waiting for your open solution,thanks.Any timeline?

I was able to flash an older version of the tp-link firmware using the TFTP method. From that I am able to use the stock tp-link web interface to install dd-wrt (here: http://download1.dd-wrt.com/dd-wrtv2/do … er-c7-v2/)

But whenever I try to flash openwrt (https://downloads.openwrt.org/chaos_cal … actory.bin), I get nothing after the reboot. I've tried the usual IP addresses and am not getting a DHCP assignment on the LAN.

Is this "flashing fine, but nothing on reboot" behavior expected with all the tp-link FCC shenanigans?

First of all, you're using an older version of CC, you should look up 15.05.1. I suspect you're flashing OpenWrt from dd-wrt and I believe you need to revert back to stock firmware first.

I can confirm Spanky's results. Sorry for the xpost, but my adventure has already been detailed over here: https://www.reddit.com/r/openwrt/commen … 811_after/

Essentially I can confirm that something else is going on here and none of the circumvention methods work.

It's to the point where I've tried everything short of getting a serial console and observing uboot. (Really not even willing to do that)

Edit: This is from a router that I received off of Amazon 3/16/16 It came with firmware:

Firmware Version: 3.14.3 Build 151014 Rel.49676n
Hardware Version: Archer C7 v2 00000000

(Last edited by xenith on 17 Mar 2016, 23:37)

Just a note. The only way I could get an Archer C7 1750 v2.0 to take openwrt was the tftp method. Renamed the file to what it was looking for and it worked perfectly.

Yep, I've been doing that all day long. While it works for all stock firmwares, (which I can then flash DD-WRT) it does not work with OpenWRT images.

Essentially the two scenarios are:

1. Revert to older stock TP-Link firmware via TFTP
    --> Go to upgrade firmware and select OpenWRT's firmware... wait for upgrade to finish, reboot.
      --> Router is in non-responsive state, but can still be recovered via TFTP (not bricked)

2. TFTP OpenWRT directly, reboots when complete
    --> Router is in non-responsive state, but can still be recovered (to a stock firmware) via TFTP

Where "router is non-responsive" means that I can not reach it on 192.168.1.1 (I have also nmapped 192.168.0.0/16 just to see if it was hiding somewhere else, nothing) and where there are only two lights present: 1. Power, 2. Network light of connected interface.

Since you weren't clear -- did you reboot the router at the end of the upgrade procedure or did you wait for it to reboot on your own? Which exact OpenWrt image are you using to flash? What is exact model of your router (including version info)?

Where did you buy the router from? Can you maybe post the labels and ideally photos of the mainboard to make sure TP-Link did not silently slip in the new hardware revision while keeping the same version number?

1. The TFTP flashing process, and in-web-UI flashing process both rebooted on their own, but I also threw in various combinations of manually rebooting, pulling the power for 5 sec, etc ...

2. Exact openwrt images:
     https://downloads.openwrt.org/chaos_cal … actory.bin
     https://downloads.openwrt.org/chaos_cal … actory.bin (straight off the wiki)

3. Yes I did verify the md5/sha256 hash

4. See below image album

5. Let me know if this is an adequate place to put this: https://imgur.com/a/AxsgF/layout/grid

(Last edited by xenith on 18 Mar 2016, 13:57)

Looks like you've done everything you possibly could -- I'm out of ideas. Post a separate thread in Devs Only section maybe? Maybe they can figure out what DD-WRT is doing differently to run on your box whereas OpenWrt can't.

Just out of curiousity, where from and how long ago did you buy it?

Amazon, three days ago.

This person, on reddit, reported that there was a hardware change in December 2015.:

https://www.reddit.com/r/openwrt/commen … er/d14ihwo

I chould be up shit's creek here. Possibly no solution if this is a locked bootloader. I have the necessary JTAG equipment but I shy away from using it unless there's a possible solution because I sometimes screw it up and destroy the device in the process. (kind of a n00b in that regard). So, I'm waiting for the other guy to move in order to see if there's something worth pursuing.

Otherwise, I'll probably just return it and start seeking alternative hardware options.

Yeah, they definitely changed something back in Nov/Dec 2015. I feel like they should have at least changed the hardware version to reflect TP-Link's new anti-consumer stance. I guess this is a case of voting with our wallets.

Another data point, I have a wa801nd v3 that has the October 2015 firmware on it.  The webinterface refused to load openwrt and also refused to load an older official tp-link firmware image.  I was able to use tftp recovery to install openwrt on this device.

Either the new firmware lock varies from device to device, or there is another problem with the Openwrt firmware on the Archer c7.  A serial connection is needed to work out what the issue is.

Based on those logs, the Archer C7 v2 is now shipping with the gd25q128 flash chip, which is not supported in the CC kernel.  The TP-link wr841nd apparently has this problem as well, based on this bug report:  https://dev.openwrt.org/ticket/19670

The upstream Kernel added support for that chip early 2015, but apparently that patch didn't make it into CC.

I suspect a trunk snapshot will work on this device, as it should have a kernel with this patch.

spanky: Awesome, thanks for the confirmation!

Great work, keyboardgnome. Thanks for your research. Reminds me of a paper I read about injecting JavaScript code on routers' HTML interfaces by using a malicious SSID.

Locking firmware upgrades is a horrible idea from TP-LINK for several reasons. Glad there's still a way through that doesn't involve TFTP and such.

Would this work (in theory, at least) on all routers with a USB port? What about those which don't have one? I'm thinking maybe multiple SSID changes could be used to concatenate a script that downloads f.sh to /tmp via wget or curl (if stock firmware has either), runs chmod +x and then executes it.

Johndoe,  I've been working on this on a device without a USB port.  There isn't a curl or wget binary available.  My approach has been to write a script to /tmp and execute it.  The httpd binary has a -k flag to kill all threads, so it should be possible to run an httpd -k followed by an httpd -f.  I've not had success with this approach yet, but I'm optimistic that it's possible.

I believe the following commands should work on a tp-link device without a usb port:

`echo "httpd -k"> /tmp/s`
`echo "sleep 10">> /tmp/s`
`echo "httpd -r&">> /tmp/s`
`echo "sleep 10">> /tmp/s`
`echo "httpd -k">> /tmp/s`
`echo "sleep 10">> /tmp/s`
`echo "httpd -f">> /tmp/s`
`sh /tmp/s`

Same process applies, punch these in as the network name to use.  Tested on a wa-801nd v3, would love to hear about other devices.

To explain what is happening here, the wifi network name can run code by using the back tick marks.  We're writing a script out to /tmp/s and then executing it.  We're killing httpd, giving it time to settle, telling httpd to reset all settings to default, and then killing that process after 10 seconds, and finally running httpd with the freeupdate tag.

oneru wrote:

Same process applies, punch these in as the network name to use.  Tested on a wa-801nd v3, would love to hear about other devices.

Didn't seem to work with an Archer C7 AC1750. I tried both the USB and non-USB methods mentioned by keyboardgnome and oneru and continued to get the Error 18005, bad name/version when attempting to flash the trunk firmware.

I jumped to the TFTP recovery method and while it took OpenWrt (and I'm pretty certain I gave it the trunk and not the stable build), I'm now stuck in a boot loop. It looks like it isn't going back into TFTP recovery, just cycling a failed boot every few seconds with the interfaces never coming up. Can I recover from this with TFTP and serial? Should I be flashing back to an older TP-Link firmware? I'd love to get some more sanity checks before I open the box since this is my first time having this much trouble.

Has anyone else successfully flashed a recent Archer C7 AC1750 with the new flash chip and firmware lockdown check? What exactly were the steps you took?

Thanks for any help!

Yes I have a modern manufactured 1/16/2016 Archer C7 v2 that is currently using the DD trunk build. I even wrote a handy script here to help bootstrap the sysupgrade process, because DD doesn't come with ath10k firmware or LuCI installed. (could that be your problem? You maybe didn't realize that and aren't SSHing in first and installing those things?)

I'm not going to go through the TFTP procedure because it's a pretty ubiquitous and detailed thing elsewhere. A key thing for me was setting up:

tcpdump -n port tftp

on the TFTP server to view its request. That's when you know it's actually working.

I recall having a bootloop as I was messing around with things and I could still get the TFTP to work by holding down the reset button after I turning the power switch on. Just wait for the 'double WPS arrows' to display, then let go of the reset button, then look for the TFTP request on your tcpdump output. It takes about 2 seconds after the WPS light is solid for the request to be made.

I might have some other information that's of use to you (like serial output logs of various scenarios, because I did take the time to solder that on and hook it up to a UART) so I encourage you to look at my post history.

In the end, they key to getting things to work on the new C7 was using DD instead of CC because it includes support for the new chip in the kernel. Without it, horrible things happen. (It really just boots and does nothing, but you can still TFTP!)

(Last edited by xenith on 25 Mar 2016, 16:59)

FWIW I'm reporting that I had success and felt the procedure an easy and non cracky way to reflash Archer C7 V2 from the latest OEM firmware to latest OpenWRT snapshot with the procedure outlined in the thread. First I downgraded to oldest OEM firmware available from TP-Link (yesterday Archer_C7_V2_V3_141110.zip) and then on OEM WebUI upgraded to OpenWRT snapshot. As a reminder the "easy way" gets one to ssh into the Archer from here on.

The hardware was bought from a local warehouse shelf yesterday. What I can tell the hardware was targed to EU and I first tried and found the latest OEM firmware/WebUI did not accept CC 15.05.1.

Union wrote:

FWIW I'm reporting that I had success and felt the procedure an easy and non cracky way to reflash Archer C7 V2 from the latest OEM firmware to latest OpenWRT snapshot with the procedure outlined in the thread. First I downgraded to oldest OEM firmware available from TP-Link (yesterday Archer_C7_V2_V3_141110.zip) and then on OEM WebUI upgraded to OpenWRT snapshot. As a reminder the "easy way" gets one to ssh into the Archer from here on.
.

Quick Question, how did you downgrade the router to the previous firmware version? At least on the firmware version I have on my Archer C7 V2 (3.14.3 Build 151014 Rel.49676n) it won't allow me to use the WebUI to restore the older firmware version. Did you have to use the tftp method or something else?

The discussion might have continued from here.