(Workaround found) TL-WR1043nd v2 wireless range / stability

Hi all,

I bought this old router to replace my even older tp link router, which I use as wireless ap. I wanted gigabit ports, so 1043nd looked good to me. Hovewer, the wifi looks a bit wonky to me on pretty much anything I flashed it with. Currently running 18.06.1 stable. For testing, the router has no internet access, just a gigabit ethernet connection to ubuntu desktop running iperf3. Wifi device is xiaomi MiNote3. In the same room, approx 4 meters from the router I'm getting ~60Mbps with iperf3. I tried all sorts of settings but the only thing that makes a difference is removing 2 of the 3 antennas. When only the middle antena is connected, I'm getting 170Mbps at the same spot. The more antennas I connect, the worse it gets... Did anyone else encouter such a thing before? Also, the speed drops significantly behind a couple of walls. The old tplink gives me 20Mbps, the 1043nd a couple of kbps - unusable - while the signal strength is roughly the same. To achieve the same signal strength, I left 1043nd's at auto (14dbm) and dialed the power on the old router down to 5dbm...

v2 (or newer) of the tl-wr1043nd should be quite o.k. (although I wouldn't buy single band devices anymore), v1 with its draft-n radio was more of a problem.

Stop the press!

For the sake of argument, I decided to compile the exact same ancient version of CC r44455 for the WR1043ND (which was a small nightmare with a new compiler and the decision of third parties to move away from ftp) to make the comparison to my old WR841ND fair. Guess what? The devices are now on par!
OFDM errors dropped considerably to ~300. Speeds and rages are now almost the same and the network response improved on the 1043. Not sure if this is a regression, or just a normal evolution. I'd be tempted to find which commit could be responsible for this, but it's been almost 4 years since CC r44455. But it would be great to have this kind of performance with a recent kernel :slight_smile:

Original post:

I have a feeling there is something wrong with the hardware of this router. Don't get me wrong, I know it's old and even when new, it was low end. I've been checking ANI and found out there are approximately 1000 OFDM errors per second. WR841ND with an ancient Chaos Calmer snapshot is reporting 250 - 600 OFDM errors per second. Suppose that could partly explain the speed is way lower with 1043 even though the signal strength is roughly the same. I still need to test the Gbit switch performance, but I expect it to be ok. I'll probably just use it as a "smart switch" then.

To continue my semi-monologue;
I made several tries with various versions and it seems wireless performs OK in Chaos Calmer until commit mac80211: update to wireless-testing 2015-03-09
CC 15.05, 15.05.1, LEDE 17.01.6, Openwrt 18.06.1 and also recent snapshots perform awfully with this old hardware. By "awfully" I mean wireless bandwidth being practically half of the bandwidth in get in CC before the commit above. Just in case anyone is still using this old router and is puzzled by the poor wifi speeds...

1 Like

@0rphu,
Thanks for trying to track it down.
So, which version of CC should I try in order to revive this router's WiFi and to make sure that I'm having the same problem as you?
In case we prove your theory, how can we fix this issue on current builds?
Thanks in advance.
Cheers

@john3voltas,
you can try and build this version: https://github.com/openwrt/archive/tree/61cd5ce994701218a033578d2174e4791c146771
Since it's pretty old, you'll most likely face issues with your compiler being too new, additional sources which are downloaded during the build will fail, because it will try to download from ftp, which no longer exists and similar issues. All of them can be worked around. I don't remember the exact steps which are needed, but if you like, I can retry the build from scratch and note what changes are necessary.
Fixing the issue in current builds could be hard. The current versions are miles away from this commit. But I know the commit in one of my previous posts broke things. It was, unfortunately a big change, so I wasn't even able to start looking for issues. The other thing is, I'm not a programmer and only work on a trial and error basis :slight_smile:

one of the issues in recent ath9k driver versions seems to be related to tx queues, and it is quite possible the kernel is the culprit. as an example, running client(laptop) on 3.2.11 with backports-4.4.2 it can easily send >200Mbps to a similar (qca9531) device at 8 or 10 iperf streams, switched laptop to 4.9 kernel and the these speeds drop to ~150Mbps if still using 10 streams, to get back close to 200Mbps i had to increase iperf streams to 20 which also results in more CPU overhead, and frequently crashes iperf. this is at least bandwidth side of the problem, for the txpower part it might be more device specific, e.g. eeprom/art parsing

Hello!

I know this is reviving a really old thread, but: Any news about this?

I want to use two old WR1043ND v2.1 as Dumb Access Points and am asking myself which version of OpenWRT I should use.

Does OpenWRT 19.07.2 still have above problems?

Should I even use Barrier Braker (it's just a dumb access point, after all)?

Hi,

I can't really answer the question, but... give the current version a try, it might just work for you. Who knows, maybe it was fixed in the meantime, I didn't check recently. All the issues I had could have been related to my specific hardware, although I don't think it is very likely. Like I've said, for me the very very old Chaos Calmer commit just works (when I bend it enough to compile on recent compilers - which I did a long time ago and sadly didn't make notes). Would be cool, if this gained some traction, but the device itself is very very old and I think the developers have their hands full maintaining code for the more recent hardware.