I have a bricked TP-Link 1043N V5 at my desk. Help?

I still think that the timing is not good, maybe you can also try the wan port. last option is the serial cable, I think you'll have to connect a missing resistor

It certainly would not hurt to try that.

As @lucize stated about the timing too, it can be really tricky and take quite a few times of trial and error to get it right.

Maybe try following the steps in this article to see if you can reach the router in failsafe mode:

Then reflash OpenWrt ("sysupgrade" not "factory") on it if you can reach failsafe.

For future reference, openwrt-xxx-factory.bin files are used only for flashing from stock firmware to OpenWrt, not reverting back to stock firmware or upgrading. So if you are able to get in to failsafe mode and get OpenWrt working on it again and wish to revert back to stock firmware, you will want to download the stock firmware off TP-Link's website for your TL-WR1043N V5. SCP that firmware to the /tmp directory of your router. Then SSH in to the router and run the following commands:

  1. cd /tmp
  2. dd if=<stock_firmware_image> of=tplink.bin skip=257 bs=512
    (In order to flash the TL-WR1043N/ND series stock firmware we need to strip the uboot image off it when flashing it under OpenWrt)
  3. mtd -r write tplink.bin firmware
    (Write the stripped firmware)

New URL: https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset#failsafe_mode

The old page is for archival purposes only and does not receive updates any more.

Go through the site tmomas posted and get a clue what is possible.
First disconnect all network adapters/cables from your system.
Install tcpdump. On debianlike distribution with
apt-get update && apt-get install tcpdump
then go on with - on old debain
change $INTERFACE to your interface

ifconfig $INTERFACE down
ifconfig $INTERFACE up
ifconfig $INTERFACE

on new debain

ip link set $INTERFACE up
ip addr add dev $INTERFACE

dont mess with netmask just give that a try:
start tcpdump
tcpdump -i $INTERFACE
start your router and press the reset button keep it pressed for 15 seconds and
read the output, you'll hopefully see the ipadress of your router asking for tftp then stop tcpdump with ctrl+c .. try to start the server with verbose output
read about it in
tftpd --help
i never use original firmware from tplink to debrick i always use the openwrt-***-factory.bin it should work if your router is compatible, so you dont have to mess around with dd.
Does the LAN LED of your router switch on when you insert the rj45-cable? Does ifconfig gives you a Scope:Link ?
Or try out
ip link to see if the network card has a physical connection to your router.
Your router will restart if he could'nt find the tftpd server tcpdump is usefull to see the timespan you have. And if the router actually boots to recovery.

good luck

@lucize What should I watch out for? I guess there would be a timing issue if it were possible for the router to go to failsafe mode but that isn't possible right now because the power LED doesn't blink. It just stays on as soon. If I press a reset button before powering on the router and keep pressing the reset button, the last LED lights up (without blinking) for maybe 5 seconds and then that goes away as well along with a single blink on the power LED. This happens even if I press the reset button after a second of starting the router.

@mj5030 Using the --verbose flag gave me nothing different.

@mj5030 Like I said before, I don't think that going into the failsafe mode is possible because the power LED doesn't blink ... at all.

@eliasmagnus Thanks for the help. However, I didn't see any output in either Wireshark or tcpdump. I tried connecting my Ethernet cable to both the LAN and WAN port and used both and No output. Nothing.

from my experience with v4, the switch leds are not blinking at all, they only stay on or off, maybe 1 seconde is too late or too soon, don't hold the reset before powering it on. I had difficulty using the recovery mode, even with serial console attached, so for you without seeing the uboot is even harder!

Sounds to me like you have a faulty cable, what could be the reason you bricked your router...

Well, I'm using that cable with another router right now and it's working just fine. :confused:

don't hold the reset before powering it on

Yeah, I tried that as well. I'm getting the same result no matter what I do.

Thanks for all the help you guys but, unfortunately, I'm not getting anywhere. Should I look into using the UART or the serial console to figure out what's wrong? I have no idea where to begin with this so there's that. I didn't know that recovering from a bricked router would be so hard. If I did, I wouldn't have tried to mess with my router carelessly.

How soon do you need a running router?

If the answer is within a week or so and you don't immediately need 802.11ac, I'd select and order one of the US $20 price-class devices from a seller that ships out of the US or wherever you may be located. I don't have one myself, but as an example of possibilities, at $20, the GL.iNet GL-MT300M-V2 looks to have a decent CPU, 128 MB RAM, 16 MB flash and ships Amazon Prime in the US. Routers in this bottom-dollar price class typically are single band, no 802.11ac / 5 GHz.

No matter the answer, I'd order a USB-to-serial adapter off eBay or through your preferred supplier. Here near San Francisco, it's usually a week or two for ePacket to arrive, sometimes up to a month for "economy shipping". So, for something around $2 for the board and $2 for shipping, having one on hand even if you never use it seems prudent. With shipping close to the price of the board, might want to get a couple if the seller's shipping is by-packet, not by-item.

Make sure which ever one you buy supports a switch, jumper, or solder bridge to select 3.3 V logic!

Also get a couple 1 kΩ resistors and maybe something around 700-800 Ω, tiny ones are OK (1/8 W or 1/4 W). Some devices need pull-up/down on their serial lines.

Lots of choices, all with their own "roll the dice" challenges, unless you pay $15 or so and go with a mainstream supplier that guarantees the authenticity of their chips. More of a problem for Windows hosts than for macOS or Linux-based hosts, from what I understand. I'm partial to the FTDI chips myself, others swear at them.

The ones I like are small enough to fit permanently inside some router cases.


This style works great for me in a "workbench" situation, but the voltage-select pins and jumper are too tall to fit inside my Archer C7 cases


Other ones out there as well, and I can't say much more than the specific ones I bought came from eBay sellers with a large number of very high ratings that focused on electronics / hobby items.

I'm using a shitty TL-WR740N with stock firmware for now. Although everything works, I don't want to use it more than I'd like.

I'm also not in the US so getting these parts might be difficult but I guess I can order this stuff from Aliexpress or GearBest. I'll definitely get this stuff but meanwhile, I think I'll just buy another router. I don't want to use a router with a firmware that's more than 2 years old and has seen no patches.

Thanks for the info!

There look to be dual-band options in that long list of options and opinions that aren't crazy expensive (US $50 or less) and could ship to you in a reasonable period of time as well. Just depends on if you consider it a back-up router, replacement router, or second router and what your budget might be.

In which country you live ? I am from germany btw.. :wink: greetings to USA jeff XD! I am using CH340G for serial communication or a AVR chip with a serial program on it sometimes when i am lazy one of my espressive chips for overtheair serial .. i dont like ftdi at all dunno wy they had a good reputation destroyed a ton of these 232 chips, dunno if i had bogus ones each time. My 340gs are working flawless since i have them.
I would not be afraid using the 740n till i fixed mine. Send us a bootlog you got via serial(UART) connection.
i really cant believe you bricked yours to another brick in the wall :wink:

@jeff I think most of the 802.11ac hardware uses proprietary firmware right? If that's the case, I think I'm fine with 802.11n for now.

I'm from India. Using a router with OpenWRT is an exotic activity here and most people use routers provided by their ISPs. Then again, most of these people consider the Internet to be comprised of Google, FB, and a few other sites.

It seems that Amazon India does have CH340G but I'm not sure which to buy. It's good that these are cheap so I'll grab whatever I like.
For now, I bought another TL-1043N v5 and flashed OWRT on it. I was thinking about buying a Mi Router 3G from Aliexpress but the 1043N was available for ~$30 and had faster delivery. However, Mi Router 3G seems like a really good deal. I don't know how well OWRT supports it.

If it's the "free and open source" discussion, that's a topic in and of itself, as I believe every modern chip of any sort on the market employs "proprietary firmware", whether you can "see" it or not. Personally, I'd rather have a chip that can be updated when flaws in the firmware or protocols are discovered, or standards change.

If it's a different question, most of the Qualcomm/Atheros 802.11ac chips work quite well with their "stock" firmware and many "like" the CT firmware as well. The MediaTek 802.11ac chips, as I understand it, now have solid drivers as well, thanks to the hard work of many working on OpenWrt.

For me, use of 802.11ac comes down to getting better throughput on 5 GHz, even in my relatively remote area. I would imagine it is even more valuable in urban or suburban areas. It may more or less of an advantage in your region, depending on the number of 80 MHz channels available without DFS (radar-detection) restrictions.

Yeah, I guess you're right about that.

The ath9k driver is pretty solid when it comes to support I think.

The 1043N doesn't have 5Ghz. Right now, using 2.4Ghz, I'm able to get ~50M on my Android on a 100M connection. Using ac 5Ghz might improve things because there are many 2.4Ghz connections available near my location.


The Bricking

The Bricking

The intention was to update wr1043n from 18.6.5 to 19.7.1. After using '*sysupgrade.bin' file two times; (the connection was too slow after both installations), it's decided to install '*factory.bin' with '--force' option. And the bricking done.

  • Don't use factory image on a target with OWrt, use sysupgrade.bin image for upgrading.

The DeBricking

a failing reason of tftp connection

I've discovered that adding ip with
#ip address add dev $INTERFACE command adds address as so the address family doesn't cover which wr1043n gets for tftp.

Right command to assign host ip;
#ip address add dev $INTERFACE

Package:'atftp' is installed for tftpd server

#mkdir /srv/atftp
#mv openwrt-19.07.1-ath79-generic-tplink_tl-wr1043n-v5-squashfs-factory.bin /srv/atftp/WR1043v5_tp_recovery.bin
#chmod --recursive 777 /srv/atftp

Don't forget to bring $INTERFACE up
#ip link set $INTERFACE up

At one terminal tcpdump was running to watch the process
#tcpdump -f -u -i $INTERFACE

To run tftp server, the following command is used on another terminal;

#atftpd --bind-address --user nobody.nobody --verbose=7 --trace --logfile - --daemon --no-fork --maxthread 300 /srv/atftp

Then started wr1043n at tftp mode by holding reset button pressed a few seconds while powering it on. I think pressing until the last led lights up is enough. It works by pressing reset before pressing the power or just after.

atftp log, try powering on multiple times if failed

Following is the tail of atftpd log. I've restarted modem many times until it reaches the last block and give 'End of transfer'. It had stopped between 100th and 5000th blocks many times. I've tried with 3 different cables and still don't know the reason for that.

Feb 14 17:56:57 archore atftpd[94000.139877711361792]: sent DATA <block: 7869, size 512>
Feb 14 17:56:57 archore atftpd[94000.139877711361792]: received ACK <block: 7869>
Feb 14 17:56:57 archore atftpd[94000.139877711361792]: sent DATA <block: 7870, size 227>
Feb 14 17:56:57 archore atftpd[94000.139877711361792]: received ACK <block: 7870>
Feb 14 17:56:57 archore atftpd[94000.139877711361792]: End of transfer
Feb 14 17:56:57 archore atftpd[94000.139877711361792]: Server thread exiting

It's 7870 blocks of size 512, I've calculated it after it stopped at different block numbers a few times.

Hope this helps the future brickers.

Tried tftp file transfer to the tl-wr1043nV5 running OWrt 19.7.1 with the same setup

Meanwhile I've tried same tftp communication to be sure about notebook port, cables etc. Used the ip given by wr1043 dhcp. Installed atftp package on OpenWrt, file transfer was staight forward. I think there's something wrong with the timing of wr1043nV5. Though I lack knowledge to go investigate further.