Having trouble installing over TFTP

Hello! I'm new to OpenWRT (and flashing routers with custom firmwares in general). I have a TP-Link Archer A7 v5 router that according to the wiki, can only be flashed over TFTP. I setup a tftpd on a server, with the -factory.bin renamed to ArcherC7v5_tp_recovery.bin, and confirmed I can download it over TFTP. However, when I configure it with the ip 192.168.0.66/24 and hook it up directly to the router, I still see my SSID pop up after rebooting it and holding the reset button, per the instructions. So all of that being said, my questions are:

  1. Do I need to set a specific router/default gateway, or does it not matter?
  2. Should I be plugged into the WAN port or one of the 4 LAN ports?
  3. Is there a way to confirm that the flash is happening, and that it was successful?
  4. Do I need to use another method to get the router to boot to the TFTP client?

In case it matters, the checksum of openwrt-19.07.4-ath79-generic-tplink_archer-a7-v5-squashfs-factory.bin is 6f3e365ad9f20839034a594aad531e9608cae154. Thank you!

No, but IP and subnet mask need to be correct.

No, unless explicitly mentioned on the device page (no).

You can bump the verbosity of your tftpd server or you can use wireshark/ tcpdump to check what's happening on the wire (bootp/ tftp requests, data transmissions, etc.).

You can connect a 3.3V serial console, both to check what's going on and to explicitly invoke tftp, bootm and associated functionality.

In case of problems, it's always a good idea to put an unmanaged switch between your router's LAN ports and your computer running the tftpd. This keeps your computer's network interface up all the time and prevents it from being deconfigured (releasing its IPs) while powering off (or rebooting) the router. On most routers, the tftp window (the timespan it looks around for the named tftpd) is rather short and anything to shorten the time the router needs to discovery and connect to your tftpd (such as link training) helps.

3 Likes

Thanks! I'll give that a shot.

I do now see 192.168.0.86 in the ARP table of my server, after putting an unmanaged switch between them. Should I be able to ping 192.168.0.86 or 192.168.1.1 at any point during this? So far I just get timeouts, "no route to host", and "host is down" messages. The ethernet port I'm plugged into on the router is actively blinking, which I'm taking for a good sign.

On a tangent, I tried to hook up a serial cable from the router to the server, but the router doesn't have a serial port. I do have a USB <-> serial adapter that I plugged into it, but I still couldn't serial into it at various speeds. Do you happen to know if the Archer model supports serial over USB (I couldn't find any attempts to do this online), and at what speed it supports it?

  • Usually, but only the OEM can tell you if the device would respond to a ping
  • Next, 192.168.0.66/24 and 192.168.1.1 are not in the same subnet, so I don't see why you would be able to ping 192.168.1.1

You were told:

If you do not have one, do not mess up your router by zapping it improperly with the normal 5 volts in USB/serial. The term for the device may also be called "TTL to Serial 3.3 V adapter".

I guess I assumed since OpenWRT sets the default IP of the router to 1.1, it would respond back since they're directly connected.

My apologies, I misunderstood what I needed to use. I don't believe I have one of those however. So there wouldn't be any other way besides that to verify the router has finished?

So what's 192.168.0.66/24?

The OpenWrt would only respond back if your computer is set with a proper IP (i.e. one that's in the same subnet of 192.168.1.1). So if you configured a device as 192.168.0.66/24, it cannot ping 192.168.1.1. Those are different subnets.

Try 192.168.1.66/24.

The server

That makes sense. I didn't consider the router wouldn't like an IP out of it's subnet, but you're right (I'm a bit rusty at networking in general, and this project is definitely something I'm not experienced in haha).

Thanks, I'll give that a shot.

192.168.1.1 worked :slight_smile: You can chalk this one up to a PEBCAK error. Thanks both of you!

1 Like