TP-Link TL-WR1043N/ND v1: Unreliable wifi, useless after ~24 hours (ANI disabled)

Thanks slh.

I'm on Australian internet (~10Mbits/s max), so I'm still definitely living in the MIPS age, and given the current political directions likely to for at least another 5 years or more.

I had no idea about the 802.11n standard dramas. I'll try disabling n and see if that changes anything.

Don't disregard the 4/32 warning either, it's becoming a real problem for actual production use.

From an outsider's perspective: the wiki page for 4/32 is a disaster of conflicting and dubious info.

The way much of the page reads tells me that I should not use OpenWRT on anything but the latest high-end stuff that's almost a raspi SBC. It makes it unclear whether using OpenWRT on lesser devices for basic oem-like tasks (no VPNs, samba, etc) is possible or recommended, hedging it with "instability" and "crashes".

This completely clashes with my understanding of the history of the project and the most popular devices OpenWRT is used on. Not to mention the opinions at the bottom of that page.

As an outsider: I'm disgregarding all of this confusing and conflicting information in preference to two very specific pieces of information:

  • This device is listed as supported hardware on the big table
  • Other users stories of having success with OpenWRT on this hardware.

I can understand the motivations of the 4/32 page -- to try and reduce the amount of issues first-time OpenWRT users have. It might achieve that goal, but I think it does it by brute force, scaring away and confusing those that remain. As a warning it's not clear or precise.

EDIT: IMHO this makes it a big deterrent to the OpenWRT project.

Please don't take offense at any of this. I'm an outside dev/user, these are my first OpenWRT experiences.

4/32 is a real problem, to the extent of opkg running into OOM conditions in recent versions, that isn't the only problem and the situation isn't going to improve in the future either (on the contrary).

I don't need to install anything, so hopefully I should be fine.

root@LEDE:~# free
             total       used       free     shared    buffers     cached
Mem:         28176      23228       4948        588        704       3644
-/+ buffers/cache:      18880       9296

4.5MB might not seem like much from some perspectives, but to me that's millions of bytes :smiley: That and there's not much else other than logs that should build up on this device.

Getting bigger might be a general slow trend of software projects, but it's defeatable.

Have you tried specifying the tx/rx antenna chains?
option txantenna '5'
option rxantenna '7'

The spec sheet for this device shows that only antennas 1+3 are correct for transmission and 1+2+3 for receive.

I only point this out because it looks like you’ve tried everything else.

I'll try that lantis. Where did you get the antenna numbers (5 & 7) from?

It’s a bit field mask. So antennas are assigned a binary value
1 = 1 (001)
2 = 2 (010)
3 = 4 (100)

Apparently the antennas are listed in the spec sheet (which I haven’t personally viewed) but I’ve seen it talked about it before.
One of our users at Gargoyle has also complained about it.

Thanks lantis.

Disabling 802.11n (using abg...): Problem still exists. Max speeds are slower during iperf tests, confirming the option change.

Adding rx/txantenna lines to device under /etc/config/wireless & restarting wireless: Problem still exists.

I'm somewhat lucky that the problem appears within minutes now, making it much easier to test.

I might try my hand at the openwrt toolchain, see if I can neuter that old patch and make a compiler very cross.

1 Like

Aussie broadband (remembers TPG being "great" for leechers because of their cheap unlimited plans and getting heavily congested) :wink:

That aside, I guess there will always be two polarized camps regarding legacy old hardware. Yes, you can use really old and slow devices which technically work but in reality doesn't get much love, isn't very compatible with newer hardware and overall gives you a rather bad user experience. The other, the newest and shinest > * . It's somewhere in between leaning towards the keep legacy hardware support. I think what the "community contributors" are trying to say is be reasonable regarding hardware choice if you want a decent experience. As an example, the TP-LINK TL-WDR3600 is a MIPS device, 8/128 and released back in 2012. It wasn't targeted at the high-end and surely didn't break the bank. This device works well even today even if WIFI performance is starting to show its age due to newer standards. There are countless of similar devices so I don't think it's being unreasonable. Being that pretty much all SoC vendors are shifting towards ARM that's where most development is targeted, I'm not saying that MIPS Is dead although in long term support ARM (v7+) is most likely the way to go. If I'm not mistaken quite a few Linux distributions are dropping 32-bit for x86, I'm not saying that OpenWrt necessarily follows the same path but I think you get the point. :slight_smile:

You can find something reasonably cheap even though prices are very high in AU in general :-/

move discussion not relevant to the issue to some other topic. wifi seem to work fine in client mode (wwan). simple search for the mentioned patch inside build dir deleting it and recompiling shoud reveal if the image without patch works fine in ap mode.

As a sidenote, would you expect a first gen Intel i5 Core CPU to perform good today? It's about 10y old hardware and I can assure you that even with 8Gb of RAM and SSD it's really slow/limited. You can't even watch Twitch in 720p without stuttering, forget about 1080p even in a standalone player with hardware acceleration (well, as much hw acceleration as it actually supports). Sure it does run Windows 7 however Linux doesn't run any better or at least Ubuntu.

Sorry for the rant (depends on your pov) :wink:

I myself have a i5 750 with 12Gb ram and where I am really limited is when I use the Dolphin emulator for RogueSquadron 3, else it runs beautiful and fast enough. Most if not all console ports are really happy with my CPU. I have to admit there are PC games like europa universalis IV which doesnt run with the fastest speed but thats an exception. I plan to upgrade the graphics card from 750GTX to 11XX because its the main limiting factor for gaming. After that my CPU so I can play Rogue Squadron 3. ^^ Ah and I had remove my Xfi PCI last week because it was crashing with Win10 1803 update... Sorry for offtopic but your reasoning was bad. :smiley:

Now ontopic, I dont know if it was the same problem but I encountered wifi stalls with my wzr-hp-g300nh one-two months ago. Maybe it was a bug in trunk but because the device has the same wifi chip as the wr1043D V1 I was reading this thread. Right now i dont encounter the problem but have to say I dont use the device regularly anymore. Today I setup it again to play with dynack so maybe I encounter the problem again.

Today, I planned to walk through the patch-and-build process.

My plan was to first build the latest stable image. Then, if that worked, I wanted to revert the changes of the mentioned commit (b30e092de65ca7be7cb277f934016484137d924c).

I managed to get a working building toolchain and was able to compile a new firmware image (YIKES) from the stable sources. I was able to flash this image, and Wifi failed immediatley, as expected.

So I was out to revert the changes of the commit.
However a simple `git revert b30e092de65' did not succeed. The commit altered more than 170 files, many of which have been changed afterwards, so I got a whole lot of conflicts and am totally lost here.

Can someone point me towards a reasonable set of changes to perform?

In https://bugs.openwrt.org/index.php?do=details&task_id=1180 the author says something about "forcing ps=false". Can anybody tell me, what this means?

where did you get the sources from? i don't even have that patch in my buildroot and i see it's not part of an upstream driver either.

I followed the instructions from here: https://openwrt.org/docs/guide-developer/quickstart-build-images

Hence, sources came from https://git.openwrt.org/openwrt/openwrt.git. And you are right, in the current stable branch, the file is gone. As I told you, I'm lost here.

Ps=false is referring to the contents of the patch itself.
There are 6 calls to ath_set_rates, and the last parameter is what controls this functionality. If you change them all to always pass in false, you’ve effectively disabled the patch with minimal effort rather than reverting an ancient commit (in my opinion).

But, I can’t find evidence of this patch anywhere. It might have been upstreamed at some point. I don’t see the results in the kernel, but I didn’t check wireless-backports

Searching for more conclusions, I found more threads, that point to our problem:

Search for OEM firmware, since you obviously cannot handle ath9k driver on your own.

Please try this firmware, contains lots of patches and tweaks for this old Atheros chipset.

And you could also try to add a crontab job to reset wifi every 24 hours. And stop httpd server after making all necessary configuration changes to save precious RAM on this router.

I experienced similar issues on the TL-WR1043ND v1, but found that a stock 17.01.04 build would run out of free memory after a while, causing all kinds of WiFi issues.

I built a very barebones 17.01.5 image without IPv6, PPP/PPPoE and OPKG + only basic LUCI, and now the device consistently has between 20%/30% free memory. Fingers crossed after running for just two days, but it seems to have fixed my issues.

I installed OpenWrt 18.06.0 r7188-b0b5c64c22 last week and Wifi seems to work just fine since then.