HCMC Journal

Pro-D 2023: unbricking a network router

29 April 2023: Martin Holmes
Minutes: 200

During the networking Pro-D task, we managed to brick one of the Archer C7 routers. Detailed below is the lengthy process we figured out to successfully de-brick it, which should apply to all Archer C7s and many other TP-Link routers.

• First download the appropriate and most up-to-date OpenWrt firmware for your router. In my case, this was https://downloads.openwrt.org/releases/22.03.5/targets/ath79/generic/openwrt-22.03.5-ath79-generic-tplink_archer-c7-v2-squashfs-factory.bin.
• Install tftpd-hpa (the TFTPD server) and tftpd (the client) on a spare computer (laptop or desktop) running Linux.
• Set up a spare router so that its running at 192.168.0.1 or 192.168.1.1 (see below; I will use the .1 subnet in the steps below), and will allow connected devices to claim ip addresses including .66 (for the server) and .86 (for the client, the bricked router). Normally, just setting the spare router to .1 and DHCP will do the trick. We used an ancient 10/100 router from 2002.
• On the spare computer, turn off the wifi (so the only connection it will have is through ethernet), and manually set its ip address to 192.168.1.66, with a subnet mask of 255.255.255.0, and the gateway as 192.168.1.1. Connect it to the router and confirm that its ethernet card has ip 192.168.1.66 (using e.g. ip addr).
• Check whether the TFPTD server is running. On modern Linux systems, when you install it, it will be started automatically as a service managed by systemd. sudo systemctl status tftpd-hpa will tell you. If it’s running, stop it.
• Find its configuration file, which for my Ubuntu 22.04 was in /etc/default/tftpd-hpa. Check that TFPT_ADDRESS is :69 (the default), and configure TFTP_OPTIONS="--secure --verbose". The latter is helpful when checking that the server is running and correctly serving files.
• Make a note of the TFPT_DIRECTORY setting, which in my case was /srv/tftp. This is the directory where you will need to put your recovery file.
• Now copy the OpenWrt firmware file into that folder, BUT CHANGE ITS NAME. Call it ArcherC7v2_tp_recovery.bin (changing the version number to match your particular Archer C7 revision; I’ll use v2 in the steps below).
• Now restart the tftpd-hpa server (sudo systemctl start tftpd-hpa).
• Use the tftp client to confirm that the server is serving the file correctly:
  cd temp
tftp 192.168.1.66
get ArcherC7v2_tp_recovery.bin
  If this succeeds, you’re ready to go. If you get errors, you’ll need to debug and fix, which you can do by tailing the syslog (tail -f /var/log/syslog) and watching what happens. I initially had an error Only absolute filenames allowed, which turned out to be caused by a typo in the tftpd-hpa config file. Other problems may be caused by permissions on the TFTPD folder or the recovery file.
• Once you have confirmed that your server is running, it’s time to connect the Archer to the other router and try to restart it in recovery mode. Note that there are many different sets of instructions for how to do this, and I had to try many different approaches before I hit on the right one; perhaps this depends on how your router was initially screwed up. The standard instruction to press and hold the WPS/Reset button during power-up did not work for me; instead I had to press that button repeatedly during bootup until the router went into a state where only the power LED was lit, and the LED next to it was flashing quickly.
• If you are tailing the logs on the TFTPD server device, you should see the router connect to it and download the firmware. (If not, try reconfiguring everything with the other subnet, 0 instead of 1, or vice versa).
• I waited plenty of time to let the router do whatever it wanted with the recovery file. It showed no change in its interface. Eventually I disconnected it from the other router and rebooted it, and it successfully came up as a new OpenWrt install on 192.168.1.1. I was then able to restore its configuration from a known-good backup.

NOTE: Various pages on the OpenWrt site and elsewhere mention both the 0 and 1 subnets; my router (US version) turned out to be looking on the .1 subnet, but there seems to be no way to know in advance. Try 1 first, since that seems to be more common.