As we are all aware, TPLink jumped the gun on the FCC decision regarding firmware lockouts which made re-flashing the devices with OpenWRT through the webUI next to impossible. After a couple weeks of disassembling and reverse engineering their changes, a friend and I came up with what we think is a quick and easy solution that anyone can do.

Requirements:
1. You will need a FAT formatted thumb drive for this to work.
2. http://busybox.net/downloads/binaries/1 … sybox-mips

Steps:
1. Take your FAT formatted thumb drive, and download the above busybox executable to the root path of the thumb drive.
2. Create a script called 'f.sh' with the following code in it:

#!/bin/sh
echo 'FREE_UPDATE = 1' >> /tmp/dec-model.conf
/tmp/usbdisk/volume1/busybox-mips kill -9 `/tmp/usbdisk/volume1/busybox-mips ps | /tmp/usbdisk/volume1/busybox-mips grep http | /tmp/usbdisk/volume1/busybox-mips awk '{ print $1 }'`
/usr/bin/httpd -f &

3. Plug in the drive to the TPLink and go to the wireless network settings, and set your SSID to: (note the difference between ` and ')

a `/tmp/usbdisk/volume1/f.sh`

4. Submit, and then go to the firmware upload part. Upload OpenWRT. Bob's your uncle.

Update: Tested and works on multiple WR710N's. Your mileage will vary at this point based on feedback below. If it works, please let this threat know so I'll keep a rolling list of devices it works for and doesn't. Also, make sure you're using TIC marks.

Works:
WR710N - 151022_US

(Last edited by keyboardgnome on 7 Mar 2016, 16:57)

Bloody brilliant!

Two questions:

1) Is this a correct version of the f.sh script from Step 2 above? (the OP version wasn't in "code" mode...) I think it's a four-line script: the second-to-last line should be really long...

#!/bin/sh
echo 'FREE_UPDATE = 1' >> /tmp/dec-model.conf
/tmp/usbdisk/volume1/busybox-mips kill -9 `/tmp/usbdisk/volume1/busybox-mips ps | /tmp/usbdisk/volume1/busybox-mips grep http | /tmp/usbdisk/volume1/busybox-mips awk '{ print $1 }'`
/usr/bin/httpd -f &

2) I don't understand Step 3: it says something about setting the SSID, and then a command that doesn't quite make sense...

(Last edited by richbhanover on 4 Mar 2016, 00:03)

That looks like a trick to get the OEM system to run arbitrary code. Apparently the SSID value is used in the wifi settings adjustment script so that a value with `backquotes gets interpreted by the shell as a command (like it does in a normal shell script). That is utilised to get the script run from the thumb drive (and that script then restarts the http server after setting the indicator file to allow any update).

Nice investigative work by the author ;-)

(Last edited by hnyman on 4 Mar 2016, 00:25)

Fixed the ambiguity

The SSID input box will accept system commands if you put them inbetween tic marks. If it doesnt work the first time, change the ssid from 'a' to 'b' (it doesnt reapply the attack if the string is the same).

This is pretty much it; I dont want to put in the other stuff I found at all (wack a mole risk), but on top of that, I'm just enabling a feature they dont have a webUI tick box for, so not really doing anything too risky.

Nice work around thanks a bunch!

I added a note to the TP-Link Archer C7 page, giving a pointer to this topic. Please consider adding a similar warning to other TP-Link device pages that you maintain. See https://wiki.openwrt.org/toh/tp-link/ar … tart_guide

Hello,
Just got new WDR3600 with new firmware, won't let me install OpenWrt !!
Tried your method every which way I could think of..................didn't work.
1. I formatted thumb drive to vfat.
2. copied busybox mips file to root and f.sh file to root.
3. went to 2.4g wireless page and entered the command into the Wireless Network Name box
4. clicked Save.
5. tried to use firmware upgrade to OpenWrt file.
6. got the error 18005...again....

Tried different commands, rebooting, hitting Enter in the command box, what ever I could think of....
never could get it to work................am I messing up somewhere????

well, I got OpenWrt on my router working, just used different method:

1. flashed ddwrt : http://www.dd-wrt.com/phpBB2/viewtopic. … ht=wdr3600
2. flashed webrevert.bin: http://www.dd-wrt.com/phpBB2/viewtopic. … p;start=30
3. flashed OpenWrt file.

It's working...............!!

sometimes i think people here arent that clever. tplink hasnt a real lockdown. weeks of reverse engineering and you still havent found that just a single byte in the header has changed? its no lockdown. its just a region code within the header which makes the trick. thats also the reason why dd-wrt can still be flashed. i added this already in september 2015  after we discovered that change

it seems i am doing something wrong.

the script is correct?

also, do i need to add a volume to the usb?

maybe stupid questions...sorry

where have u posted?

Yeah, I tried the DD-WRT firmware and multiple other methods to no avail. This has worked on multiple WR710N's so far. Instead of attacking a solution and providing no meaningful discussion, maybe you can be helpful and document in detail a solution that works? As I mentioned before, the solutions posted by DD-WRT did NOT work for this firmware, hence spending time on it.

Which byte(s) are you referring to (there's a lot of difference between the versions)? This firmware (151022_US) came out in late October 2015, so I don't know which solution you're referring to.

(Last edited by keyboardgnome on 7 Mar 2016, 17:00)

Oh goodie! I should make a noted change to the comments above. I just pulled the firmware for this version and compared it to the one for the TPLinks I have; they are different.

Works for TL-WR710N(EU), v2.1, 07/05/15

Just flashed a 3600 last week. 

I used this file from DD-WRT and flashed to a old TPLink fw that allows another flash of the OpenWRT firmware.

http://www.dd-wrt.com/phpBB2/viewtopic. … 86#1012686
HTH.

Two unrelated questions .....

1) how do you tell you are getting the model of TL-WR710N that has the 8M flash chip?

2) is this 3600 a good performing router when compared to those from other mfgs at almost double the price?

Thank you.

**** I just found the info regarding the 710N, however, unfortunately the retailers I find selling them don't seem to list the version numbers to this level of detail.  https://wiki.openwrt.org/toh/tp-link/tl-wr710n

**** Looks like many of the negative comments describe a short lifespan for the TL-WDR3600 or other connectivity problems that upgrades or changes in firmware don't resolve,  (See the comments on this device http://www.newegg.com/Product/Product.a … 833704144)  Also noting that some of the lower ratings on Amazon regard longevity as well.   So early failure appears to be an issue with this as well as initial firmware issue, which I am assuming OpenWRT helps.    Note: It's always hard to determine how to react when you see a 4 star average of comments and the negative ones are consistent in the area of describing how the product fails after a year or two, and considering all the positive ones could conceivably be early on.   Right now I'm thinking I will continue to look elsewhere for a similar OpenWRT supported router in the $50US-$100US price range.

(Last edited by DonJuane on 8 Mar 2016, 18:33)

just what i was thinking about while looking at TL-WA5210G v2 fw. but still russians haven't released nanostation flasher for v2...maybe you could double check this?

I'm ultra-new to OpenWRT but setting the region code should be relatively easy and it's been done before, see this post: https://forum.openwrt.org/viewtopic.php?id=49390

Based on this it looks like setting the region code in the header just needs to be done somewhere in this make file:
https://github.com/openwrt/openwrt/blob … e/Makefile

Anyone know what specifically we need to change?
There's a reference to a region code on line 2158 and the TL-WR710N hardware is around line 646

I also dug through the DD-WRT SVN to see where / how they're setting this region code... I found a couple instances where BrainSlayer changed the make file to accommodate for this:
http://svn.dd-wrt.com/changeset/28080
http://svn.dd-wrt.com/changeset/28079

Which led me to here:
http://svn.dd-wrt.com/browser/src/route … pb42#L1732

But I'm not sure what we need to do specifically to extend the makefile for OpenWRT to mimic the region code setting done in DD-WRT.

yes the US firmware i provide is exact the solution i'm talking about. this just has a changed firmware cheader which sets the correct region code for flashing. there is no lock down. rigtht after the hw revision just a region code has been added which is "1" for US america and "0" for anything else like before.

in addition

http://svn.dd-wrt.com/browser/src/route … tplinkfw.c

struct fw_header {
100            uint32_t        version;        /* header version */
101            char            vendor_name[24];
102            char            fw_version[36];
103            uint32_t        hw_id;          /* hardware id */
104            uint32_t        hw_rev;         /* hardware revision */
105            uint32_t        area_code;
106            uint8_t         md5sum1[MD5SUM_LEN];
107            uint32_t        unk2;
108            uint8_t         md5sum2[MD5SUM_LEN];
109            uint32_t        unk3;
110            uint32_t        kernel_la;      /* kernel load address */
111            uint32_t        kernel_ep;      /* kernel entry point */
112            uint32_t        fw_length;      /* total length of the firmware */
113            uint32_t        kernel_ofs;     /* kernel data offset */
114            uint32_t        kernel_len;     /* kernel data length */
115            uint32_t        rootfs_ofs;     /* rootfs data offset */
116            uint32_t        rootfs_len;     /* rootfs data length */
117            uint32_t        boot_ofs;       /* bootloader data offset */
118            uint32_t        boot_len;       /* bootloader data length */
119            uint16_t        ver_hi;
120            uint16_t        ver_mid;
121            uint16_t        ver_lo;
122            uint8_t         pad[354];
123    } __attribute__ ((packed));
124   

the area_code mentioned in the header was previously unused and a zero field. if its set to 1, the new so  called "lockdown" firmware will accept a firmware upgrade. thats all. you just need to adjust mktplinkfw.c a litte bit, or use mine for testing. the current version has a "-u" commandline parameter and will adjust this setting

the v2 is based on vxworks and does not use the same firmware format. since the last firmware was released in 2014 it should not be affected

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