OpenWrt Forum Archive

Topic: TL-WR1043ND intermittent reboots

The content of this topic has been archived on 19 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I have a TL-WR1043NDwhich exhibits intermittent reboots under certain conditions. When I try to fully load the WLAN it will reboot almost guaranteed (say transfer a file via SMB from one wired GbE client to a WLAN client). But also under some other usage scenarios where the load isn't particularly high it reboots occasionally. Light web browsing and also downloading from WAN works quite stable so far.

I already tried to log to a USB drive to get some ideas about the cause, but the results were not very helpful so far.

The problem occurred both on the BB release as well as the latest CC trunk (r44541).

I'd be grateful for any advice to debug and potentially fix this issue. I also thought about it being a hardware issue, but I'm not sure how I could verify that.

Thanks in advance!

i had one dowing that it was the power supply. put another one on and fixed it.

I agree with ckm. Replace power supply

Any idea where I can get a compatible power supply? Is the DC barrel a standard sized one for 12V DC? I know the PSU needs to be able to deliver at least 1.5A in this case, more shouldn't hurt, but obviously the barrel must fit.

SCF wrote:

Is the DC barrel a standard sized one for 12V DC?

No, there are several types out there with different outer and inner diameter and length.

you can cut off the cable of your old power supply and connect it to antoher 12V DC with enough Ampere. use Screw terminals if you can't solder

I was able to run a few more tests with PSUs borrowed from external HDDs that have the proper specs (12V, min 1.5A) and a fitting barrel. Unfortunately the behavior remains. Given I have tried two other PSUs (so three in total with the original one), I'd say it's not the PSU but something else.

I also ran further tests and found that when the WiFi is in HT20 mode it takes longer for the router to reboot (it would steadily transfer at around 70% WLAN load, so 5-6MB/s). In HT40 mode it would reboot almost instantly after starting a file transfer (it would shortly transfer at 70% WLAN load with around 12MB/s). Given there are several threads both in this and Gargoyle forums discussing problems with HT40 on the WR1043ND (for example here: https://forum.openwrt.org/viewtopic.php?id=42539) I wonder if this is some nasty software bug.

It could still be a hardware issue but in this case I suppose it is some onboard component and not the PSU.

Any ideas?

SCF wrote:

I was able to run a few more tests with PSUs borrowed from external HDDs that have the proper specs (12V, min 1.5A) and a fitting barrel. Unfortunately the behavior remains. Given I have tried two other PSUs (so three in total with the original one), I'd say it's not the PSU but something else.

I also ran further tests and found that when the WiFi is in HT20 mode it takes longer for the router to reboot (it would steadily transfer at around 70% WLAN load, so 5-6MB/s). In HT40 mode it would reboot almost instantly after starting a file transfer (it would shortly transfer at 70% WLAN load with around 12MB/s). Given there are several threads both in this and Gargoyle forums discussing problems with HT40 on the WR1043ND (for example here: https://forum.openwrt.org/viewtopic.php?id=42539) I wonder if this is some nasty software bug.

It could still be a hardware issue but in this case I suppose it is some onboard component and not the PSU.

Any ideas?

does it reboot or you just lose wifi connection? you can check uptime to see

It reboots as is evident by uptime and also a disconnected wired connection.

Few things to check
1) memtest check is the RAM error free?
2) Harddisk Power Check is harddisk independently powered?
3) any 'special' stuff done to the SoC like overclocking ?

1) How do I run memtest on openwrt?
2) I'm puzzled about this one, there is no HDD involved. I just took a compatible PSU from a 3.5" external HDD to power the router to rule out the original PSU is at fault as suggested by other users. Since the behavior didn't change I went back to using the original PSU.
3) No.

opkg update
opkg install memtester
memtester 32M

SCF wrote:

It reboots as is evident by uptime and also a disconnected wired connection.

id go for overheating try G only standard for a while or wired only or lower wifi power

memtester wouln't run with 32M because only around 14MB are free. But when i start it with smaller memsizes that are available it would finish testing loops ok, with 99% CPU load at this time.

@ckm: Will do in a few days. Is there some changelog available what you modified?

I set it to HT20 for now and it seems to be more stable but I have seen it reboot at least once under load as well. As if that reduces the odds of that happening. With HT40 any high wifi load will instantly make it reboot. Wouldn't overheating take a while to have an effect?

Also running only in G mode might help but isn't useful, then I can go straight back to the good old WRT54 ;-)

SCF wrote:

...
Also running only in G mode might help but isn't useful, then I can go straight back to the good old WRT54 ;-)

for debugging it would help..
try this http://www.gargoyle-router.com/phpbb/vi … amp;t=4667
i did that 12 days ago and no drop since but im running G mode

makarel wrote:
SCF wrote:

...
Also running only in G mode might help but isn't useful, then I can go straight back to the good old WRT54 ;-)

for debugging it would help..
try this http://www.gargoyle-router.com/phpbb/vi … amp;t=4667
i did that 12 days ago and no drop since but im running G mode

The setting mentioned in the link is not available on my router.

It seems fairly stable now with HT20, so I will leave it at that. No need to go back to HT disabled for now. But optimally would be working HT40 operation.

(Last edited by SCF on 12 Mar 2015, 14:03)

One more update on this issue from my side. In the meantime I got another router and then experimented with the stock firmware on the TL-WR1043ND. I flashed a stripped stock image and did the same WLAN to LAN SMB transfer test. With the stock firmware it didn't reboot at all and worked stable.

Then a bit annoyed about this behavior I flashed the 14.07 BB factory image and repeated the test. Now it worked stable as well. I have no idea what caused the behavior before, but it was clearly reproducable. The only difference I could spot is that before I initially installed 12.09 AA and later used a sysupgrade image to upgrade to 14.07 BB. Could it be possible that any leftover configuration caused this behavior? Or could it be that somehow parts of the firmware got corrupted and now that I reflashed this corruption is gone? I'm merely asking for better understanding and also so other people could better understand such issues if encountered in the future.

SCF wrote:

... The only difference I could spot is that before I initially installed 12.09 AA and later used a sysupgrade image to upgrade to 14.07 BB. Could it be possible that any leftover configuration caused this behavior? Or could it be that somehow parts of the firmware got corrupted and now that I reflashed this corruption is gone? I'm merely asking for better understanding and also so other people could better understand such issues if encountered in the future.

https://forum.openwrt.org/viewtopic.php?id=34572
seems the data partition doesnt get erased in case of sysupgrade so you have settings from old firmware

I have one final update on the matter. After trying to use the router again the same issue came up again. This time I was also able to reproduce it using the stock firmware multiple times. It seemed to be a weird issue that's somewhat linked to overheating of some component as it takes a while till it happens especially if the router was cold-booted after sitting around a while.

I just wanted to share this with the community, so people aren't afraid of using sysupgrade image for no good reason.

Since there was one year left on the warranty I now try to RMA it.

The discussion might have continued from here.