De-Bricking the TP-Link AC1750

Just before selling the Archer C7 V2 (AC1750) on Ebay I wanted to reset the router properly, but also install its original TP-Link firmware onto the same. I don't know if the new owner is savvy enough to use OpenWRT :-)

The generic uninstallation page states:

To flash the original firmware back again via the bootloader, please follow the procedures already described in Installing OpenWrt. They are basically the same.

...and over there one can read:

Non-developers should always use OpenWrt LuCI-based approaches when available.

On this late afternoon I did not want to "take any chances" (hah!) to fiddle around with mtd and writing to block devices and went on to flash the TP-Link firmware via the GUI. Ignored the warning too, because we know what we're doing :-|

openwrt_warning

The front LEDs on the router began to flash, would stop flashing, and then started flashing again, and after doing that a few times it became clear the router was stuck in some kind of reboot loop. After summoning the router gods and sacrificing a chicken I turned to the interwebs to resolve this pickle. Lot's of tutorials out there, bad ones of course, but good ones too, and even a working example from the TP-Link forum too so let's quickly summarize how this was solved on a Fedora Linux system:

Instead of installing a separate TFTP server, we were able to use Dnsmasq that was already installed on the system. Configure as described and the configuration file would look like this:

$ grep ^[a-z] /etc/dnsmasq.d/tftp.conf
port=0
interface=eth0
bind-interfaces
dhcp-range=192.168.0.50,192.168.0.150,12h
dhcp-vendorclass=set:pxe,PXEClient
dhcp-option=option:router
dhcp-option=option:dns-server
dhcp-ignore=tag:!known
dhcp-ignore=tag:!pxe
enable-tftp=eth0
tftp-root=/srv
dhcp-boot=ArcherC7v2_en_us_180114.bin
log-queries
log-facility=/var/log/dnsmasq.log

The dhcp-boot file is the original TP-Link firmware and was saved to /srv/. We needed to disable SELinux for now otherwise dnsmasq would complain with:

dnsmasq: TFTP directory /srv inaccessible: Permission denied

OK, our TFTP server should be running now:

$ getent services tftp/udp
tftp                  69/udp

$ sudo netstat -lnup | grep :69
udp   0 0 0.0.0.0:69      0.0.0.0:*      1885/dnsmasq

So far, so good. But how do we coerce the router to request the image from the TFTP server? The OpenWRT Failsafe entry states:

To enter Failsafe-Mode press the WPS/Reset Button rapidly after starting the router. Stop when the second LED (from left) starts flashing very rapidly.

...but that never happened. The router would just continue with its reboot loop, no matter how fast or how long the Reset button was pressed. Let's look if the router does anything else besides rebooting:

$ sudo tcpdump -i eth0 -n port 69
[...]
IP 192.168.0.86.redstorm_join > 192.168.0.66.tftp: TFTP, length 45, RRQ "ArcherC7v2_tp_recovery.bin" octet timeout 3
IP 192.168.0.86.redstorm_join > 192.168.0.66.tftp: TFTP, length 45, RRQ "ArcherC7v2_tp_recovery.bin" octet timeout 3
IP 192.168.0.86.redstorm_join > 192.168.0.66.tftp: TFTP, length 45, RRQ "ArcherC7v2_tp_recovery.bin" octet timeout 3

Interesting! So, the router wants to retrieve a specially named recovery file from a certain IP address only, 192.168.0.66 - just as described in the forum article! Well, we can do that:

$ sudo ifconfig eth0 192.168.0.66 netmask 255.255.255.0
$ cd /srv/
$ sudo ln ArcherC7v2_en_us_180114.bin ArcherC7v2_tp_recovery.bin

And sure enough, in the next reboot cycle the image could be retrieved by the router:

$ sudo tail -f /var/log/dnsmasq.log
Jan  3 18:49:16 dnsmasq-tftp[558493]: sent /srv/ArcherC7v2_tp_recovery.bin to 192.168.0.86

After more LED flashing and another reboot the router was back online, with its original (and ugly) TP-Link firmware running just fine. \o/