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

Installing and Using OpenWrt
#18

Without trying to step on anyones toes I think you have to accept the fact that old hardware doesn't always work as good as you remember, that new software usually is more demanding than older versions and the fact that older hardware doesn't play all that nice.

The TL-WR1043ND v1 uses about 10y old chipset/radio hardware, build quality wasn't great to begin with and I'm pretty sure AR9103 is the first or possibly second gen 11n draft-n by Atheros. It doesn't perform very well if you compare it to later generations of 11n hardware that isn't draft-n even when it works. From my last experiences years ago I never saw performance go above ~40-50mbit (usually a bit lower) using wireless without any interfering networks around and it dropped off quickly and showed strange behavior once you added neighboring networks that would cause interference or even certain types of clients. It might be down to hardware revisions but that's at least my experience with the few I had around.

You need to consider that due to the age and availability there's little hardware still around and probably very few if any developers who still tests (and runs) such old hardware. It could also very well be that there's not much else one can do (ie hardware limitations) as far as driver optimization goes. Also the fact that it only has 32Mbyte of RAM isn't in your favor. https://openwrt.org/supported_devices/432_warning

In the end you might want to consider if it's worth your time even if you might never get it to work acceptable or bite the sour apple and shell out ~50$+ depending on your needs. I know people want to keep hardware as long as possible but sometimes you have to accept the fact hardware needs to be replaced.

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:

2 Likes
#19

All good dizzy :slight_smile:

If it's a hardware issue we're looking at then it's a complete dud. This morning this device can't hold a link for more than a few minutes and packet drops ~50%, so I have to reboot it again. The suggestions of others that it could be related to long-standing bugs is my remaining rope.

Software & dev perspective: you young whippersnappers complaining about routers that are more than a few years old :stuck_out_tongue:

More seriously: I'm under the impression that most modern router chipsets are heavily rooted in historical designs, as evidenced by the dominating MIPS lineages and related stories of CPU licensing. They have not needed to increase the processing power, power efficiency or system specs in the vast majority of units, only bring down manufacture costs.

Performance and memory: I'm not after any special features that need the RAM, just something that is "better than OEM", because every oem unit I have used has had some nasty issues. I'm talking devices that secretly and unexplainably don't like certain MAC addresses, like the one on my laptop's in-built wifi phy. Change the MAC and everything works fine. Re-use that MAC on a desktop's ethernet phy and now that interface has the same issues. Fully factory reset the router and scour its settings to no avail. All sorts of fun.

As a sidenote, would you expect a first gen Intel i5 Core CPU to perform good today?

Muahaha, you are talking to a person that lives off retro hardware >:D. Circa 2011 desktop processors stopped their massive gains in speed every release as physical limits to their design became much harder to overcome. A 2008 era processor is quite a bit prior to this, but it's still more than enough for the things you list.

Anyway, I get your point. A few months back I was given this device by a friend and I was thrilled with its performance when I put OpenWRT on it, compared to my existing units that are not supported by openwrt. I know it can perform well for long periods (~few weeks), this problem appears to be triggered by something.

#20

That was certainly true between ~2005 and ~2015, where SOC internals and performance didn't change that much (mostly simple frequency scaling between 400- and 720 MHz, with minimal improvements in the CPU core IP), except for adding more current wlan cards on top. However since >50 MBit/s WAN connections and wlan standards rivaling 1 GBit/s ethernet have become common, the old mips cores can no longer scale and more performance is needed. Not even to start with users' expectations of doubling up the router as NAS, media server with indexing and even minor transcoding/ streaming requirements, VPN endpoint, these tasks suddenly need performance, probably even more so in the consumer market than the business market (where you can go a long way with hardware accelerated routing and IPsec hwcrypto). Despite the little amount of development for the mips archtitecture since it stopped being a viable high-performance RISC workstation target, it had the capability to scale up to dual-core and roundabout 1 GHz clockspeed, but ARMv7 and ARMv8 have overtaken mips in terms of processing power (thanks to the smartphone development) and finally managed to dabble into mips' old advantage of high-performance I/O connections (PCIe, SATA, etc.).

In terms of wlan stability and reliability @diizzy is totally spot on, there is a massive difference between first generation draft-n silicon and more contemporary wlan chipsets released after the 802.11n standard was finalized. Keep in mind that draft-n devices had already entered the mass market over a year before the standard had been released, while changes were still being made, and driver/ firmware changes only go this far. Some of these changes in the final 802.11n standard mean that hardware acceleration can't be used for all circumstances, requiring to do the encryption on the system SOC instead of the wlan hardware, this isn't much of a problem for x86 gear that has plenty of performance to spare, but this is a burden for 400 MHz mips SOCs. Another problem are actual hardware (silicon) bugs in these early chipsets that were rushed to market, they didn't quite get the time to mature in the lab, but in the user's hands instead - with fixes being applied to later silicon instead.

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

1 Like
#21

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.

#22

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).

#23

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.

#24

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.

#25

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

#26

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.

#27

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
#28

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 :-/

#29

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.

#30 
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.

#31

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?

#32

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.

#33

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.

#34

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

#35

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

#36

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

#37

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.