TP-Link TL-WR1043N/ND v1.8 broken?

I am totally confused with an old TP-Link TL-WR1043N/ND v1.8. After I had no space, I set it up new. Everything was fine, Wifi was setup and discovered by a mobile phone. Nothing special.

I used halt with ssh. Could that be a problem?

Then I put it at another floor and the same phone didn't find the wifi-network. I checked the cable to the Fritzbox, everyhting looked fine, but didn't work. So I connected it again to my notebook, which I used for setup of Openwrt. But I cannot connect to the router anymore. The network of the notebook and the router are the same.

So the router seems to be broken, but it is hard to believe
The cable could be broken, but I tried a different one in the other floor

The LEDs show PWR and SYS only, WLAN and Ports are off, That is exactly what I experience.

Do you think the router is broken or was it a mistake to use halt?

https://oldwiki.archive.openwrt.org/toh/tp-link/tl-wr1043nd
https://oldwiki.archive.openwrt.org/toh/tp-link/tl-wr1043nd#firmware_flashing

Flashing / Recovery using tftp only (without serial console)

If your device doesn't even boot (e.g. due to a bad flash), and your device is recent enough (circa 2011, v1.8+), you can use the device built-in auto tftp recovery process.

Connect the device (one of the LAN ports) to a host computer via an ethernet cable
Change the host computer IP address (manual or static) to 192.168.0.66
Install a tftp server. This is host computer OS specific.
    On Mac OS X, you can start the built-in tftp server with $ sudo launchctl load -w /System/Library/LaunchDaemons/tftp.plist
Download a desired firmware (openwrt *factory.bin or the original firmware wr1043nv1_*_boot*.bin) and rename the *.bin file to wr1043v1_tp_recovery.bin in the tftpboot directory (if you use Tftpd check log viewer for read request from your router, to make sure your rename is correct). The v4 file needs to be named wr1043ndv4_tp_recovery.bin.
    On Mac OS X, copy the renamed file to /private/tftpboot/
Use a pin or paper clip to press down the reset button (in the hole besides the power adapter hole) and connect the power, while holding down the reset button for a few seconds
The LEDs should flash indicating firmware upload in progress.
The device will automatically boot to use the new firmware after flashing.

So can I simply try to flash with tftp? Which file?

This is installed:
Model TP-Link TL-WR1043N/ND v1
Architecture Atheros AR9132 rev 2
Firmware Version OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152)
Kernel Version 4.9.120

https://openwrt.org/toh/tp-link/tl-wr1043nd is another link.

What about what you've already quoted from the wiki isn't understandable?

If that isn't reasonably clear, I'd like to edit it to improve it.

image

Perhaps you should consider scaling back your far-ranging goals and experiments until you are more comfortable with basic and intermediate use of OpenWrt.

I do not understand if 1.8+ means, if it works with 1.8 already.

2nd, I do not understand which file I need since there is openwrt installed already. The wiki says "factory", but openwrt is installed already and I assume the halt command disabled the ports and Wifi and doesn't activate the ports after a reboot. If this happened really, then this is a bug.

I needed about 10 minutes to get the rooter work again after there was no space, so I think I am not so unfamiliar with basic openwrt.

The intent there is, I believe, that it works for versions 1.8 and later.

You are offering 2 versions. Do you now understand why I am asking? I need a recommendation for 1 version.

I have no clue why you're asking, which is why I asked what part of the directions you replicated in your own post you were having difficulties with. I realize that sometimes the wiki makes assumptions about the knowledge of its readers that may be inappropriate, and I'm struggling to see where it could be significantly clearer on which of those two versions to use.

image

image

In case, for some reason, you need the OEM version (outdated, with 2014 being the latest release)

image

Don't you think this is a special situation? I assume I have a working openwrt-installation with disabled ports (or the router is really broken) . I assume that the wiki is talking about the situation when you try to flash from an existing stock-firmware. Normally, if you have openwrt installed already you use a sysupgrade and not a factory-file and that is why I am asking.

If your device doesn't even boot (e.g. due to a bad flash), and your device is recent enough (circa 2011, v1.8+ ), you can use the device built-in auto tftp recovery process.

Download a desired firmware (openwrt *factory.bin [...]

Yes, but you aren't running sysupgrade, so you're using the boot loader and the boot loader is OEM firmware, which accepts OEM-format images.

I didn't see your last post before flashing. I used openwrt-18.06.1-ar71xx-generic-tl-wr1043nd-v1-squashfs-sysupgrade.bin with tftp and the router works again. During flashing I saw the port led on! So IMHO there is a bug or behavior which doesn't make sense to shut down every possible access to the router.

What I wounder is, that the password survived after flashing. It survived after "umount /overlay && firstboot && reboot" too.

Thanks for helping!

It looks like the router is somehow broken. In the meantime I flashed the factory-file too. It works fine as long as the rooter is not rebooted. I can connect via ssh and after a reboot I cannot connect via ssh or luci anymore. What changed after the 2 flashings, is, that the port led shows on, if a cable is connected.

After the "factory-flash" the old password is still active. Isn't this strange? So could it be, that the flashing isn't done correctly?

Could it happen that No space left on device (no space left on device) made the router unusable? Actually it is no problem, I have 4 more TL-WR1043N/ND v1.8 and I will buy a C7 in the next weeks.

It would be a valuable exercise to think about how you could have (a) erased your overlay file system, or (b) flashed new firmware and still have your configured password present. At least to me, the presence of your password on a single-firmware device seems inconsistent with either of those being successful, not to mention both.

It would also be a valuable exercise to learn how to get your device into "failsafe" mode.