TL-WR841N v13 WiFi not stable?


#123

Hello.

I will keep my builds updated because in my last build, i changed 2 things from default Openwrt settings that mades my router better.

  1. I set the option KERNEL_FRAGMENT_CACHE_SIZE from 3 to 1 (the idea is increase available RAM, one problem to this router).
  2. I stripped the unnecessary exports to Kernel and unnecessary libraries (the idea is save CPU usage).

OpenVPN it´s included now.

https://my.pcloud.com/publink/show?code=kZXz3T7Zhr7RvDQxnw8YGb6DOA9xdRwVwPbk

Juliano


#124

@julianocs

I build from master by git pull + update feeds.

Perhaps I'm missing something? Checking https://github.com/openwrt/mt76 I can see just one change, namely "mt7603: implement support for SMPS", and, by doing git pull right now I can't see any changes related to mt76.

I'm not really used to follow development so closely, usually I work with the stable branch to get images<4MB and avoid master. So I wonder were you get those informations about latest commits. Could you elaborate further about knowing when the commits are done?


#125

Hello @tatel

Hello.

You can check the latest Openwrt commits on GitHub.
https://github.com/openwrt/openwrt

To customize the mt76 drivers, you have to modify de Makefile in
/package/kernel/mt76

I´m compiling a new build now, with the latest mt76 drivers wich
isn´t included in Openwrt master branch yet.
The link in GitHub is this:
https://github.com/openwrt/mt76/tree/aa470d8655c6b95c9930be768e9b85d95abc0314
So i modify my MakeFile to:

PKG_SOURCE_URL:=https://github.com/openwrt/mt76
PKG_SOURCE_PROTO:=git
PKG_SOURCE_DATE:=2019-01-22
PKG_SOURCE_VERSION:=aa470d8655c6b95c9930be768e9b85d95abc0314
PKG_MIRROR_HASH:=skip

After edit the MakeFile, you have to run the command "git pull" to update.
You will not see anything related to mt76 , but the new driver will be downloaded and compiled.

Juliano


#126

@ Julianocs
Thank you Sir!

But I still wonder where the part /tree/aa470d8655c6b95c9930be768e9b85d95abc0314 comes from or where is it notified (if it is notified)

No need to detailed info, but a link to relevant documentation will be helpful.

Thank you again


#127

Hello @tatel

1

2


#128

OK, now I see it.

Thank you again


#129

Snapshot version from last week is working well so far. Vast improvement in reliability compared to a month ago. Makes me happy!


#131

I've tried stable FW from 17 January, it's the worst I've seen so far. WiFi is highly unstable, and when it magically connects it just takes a few steps away from the router for it to not be able to connect any longer, the stable branch is complete trash. Wireless authentication problems are rampant:

Thu Aug 16 08:04:21 2018 daemon.info hostapd: wlan0: STA 0c:d7:46:d8:3a:dd IEEE 802.11: disassociated
Thu Aug 16 08:04:21 2018 daemon.notice hostapd: wlan0: STA d8:32:e3:9f:9c:81 IEEE 802.11: did not acknowledge authentication response
Thu Aug 16 08:04:22 2018 daemon.info hostapd: wlan0: STA 0c:d7:46:d8:3a:dd IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu Aug 16 08:04:23 2018 daemon.notice hostapd: wlan0: STA 70:28:8b:bc:bc:fe IEEE 802.11: did not acknowledge authentication response
Thu Aug 16 08:04:27 2018 daemon.info hostapd: wlan0: STA 44:6e:e5:36:59:37 IEEE 802.11: disassociated due to inactivity
Thu Aug 16 08:04:28 2018 daemon.info hostapd: wlan0: STA 44:6e:e5:36:59:37 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu Aug 16 08:04:31 2018 daemon.notice hostapd: wlan0: STA 74:4a:a4:fa:ad:f8 IEEE 802.11: did not acknowledge authentication response
Thu Aug 16 08:04:35 2018 daemon.notice hostapd: wlan0: STA e4:fb:8f:1c:d4:13 IEEE 802.11: did not acknowledge authentication response

Ignore times.


#132

Applying the latest snapshot seems to resolve the instability seen in the "stable" branch.


#133

@ner0

Felix commited a new driver few hours after your message.
Try the latest snapshot, it should be more stable than previosly.

I´m compiling a new build now, i will post tomorrow.

Juliano


#134

@julianocs Thanks for the heads-up, the snapshot from 29th was pretty decent already - and I was particularly ranting about the fact that the recent "stable" firmware from the 17th was actually the most unstable crap I've tried so far on this router.

In any case, I'll make sure to update it with the latest snapshot since so much effort is being put into stabilizing the driver. Btw, I was keeping an eye on the Github page for mt76, yet the last commit there is from 3 days ago. I'm pretty sure someone already asked you this, but I have to anyway: where can you spot the latest commits and those then being merged into the snapshot branch?

Thanks!


#135

@ner0

Just as I explained to @tatel a few days ago.

This is the direct link to the master branch.
https://github.com/openwrt/openwrt/commits/master

Regards,
Juliano


#136

@ner0

If something doesn't work in stable when released, fixes don't go to stable, but to master.

So trying to fix WR841 v13 by building stable is a waste of time, you need go to master.

Next stable release will have that probably fixed so revert to stable will be the way to go.

Cheers


#137

Felix Fietkau has been doing most of the driver updates to make mt76 functional. You can see the mt76 development commits at: https://github.com/openwrt/mt76/commits/master

Felix then periodically merges those into the snapshot branch, which you can see in this filter link
https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=HEAD&st=commit&s=Fietkau

Assuming the snapshot build works smoothly, they are available ~30h later.


#138

Hello.

I compiled a new snapshot build write now, with latest drivers...
It is on my pCloud, for whoever is interested.

As @twinkleLED saids, many thanks to Felix, all these improvements are merit of him.

https://my.pcloud.com/publink/show?code=kZXz3T7Zhr7RvDQxnw8YGb6DOA9xdRwVwPbk

Juliano

P.S.: Thanks for all developers! @nbd168, @sgruszka , @LorenzoBianconi and OpenWrt team...


#139

Wow thats awesome, thanks to the developers!

Openwrt 18.06.2 builds just released, its looking more stable, but I need to test a bit more.

openwrt-18.06.2-ramips-mt76x8-tl-wr841n-v13-squashfs-tftp-recovery.bin (release date Thu Jan 31 02:55:15 2019)

openwrt-18.06.2-ramips-mt76x8-tl-wr841n-v13-squashfs-sysupgrade.bin (release date Thu Jan 31 02:55:15 2019)


#140

Just tested now with sysupgrade.bin and its very bad for me. Every minute its dropping the packet, few website are even failing to load (speedtest.net). I have v9 router with openwrt and thats working flawless, not sure what I am doing wrong.

Anybody else having this issue?

Ping result:

PING google.com (216.58.200.142): 56 data bytes
64 bytes from 216.58.200.142: icmp_seq=0 ttl=49 time=42.748 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
64 bytes from 216.58.200.142: icmp_seq=27 ttl=49 time=1007.432 ms
64 bytes from 216.58.200.142: icmp_seq=28 ttl=49 time=42.376 ms
64 bytes from 216.58.200.142: icmp_seq=29 ttl=49 time=44.239 ms
64 bytes from 216.58.200.142: icmp_seq=30 ttl=49 time=41.850 ms
64 bytes from 216.58.200.142: icmp_seq=31 ttl=49 time=41.768 ms
64 bytes from 216.58.200.142: icmp_seq=32 ttl=49 time=42.523 ms
64 bytes from 216.58.200.142: icmp_seq=33 ttl=49 time=42.752 ms
64 bytes from 216.58.200.142: icmp_seq=34 ttl=49 time=43.078 ms
64 bytes from 216.58.200.142: icmp_seq=35 ttl=49 time=42.775 ms
64 bytes from 216.58.200.142: icmp_seq=36 ttl=49 time=42.731 ms
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40
Request timeout for icmp_seq 41
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
Request timeout for icmp_seq 44

#141

@Santosh check the bug reports for the mt76 driver.


#142

@Santosh I had some issues with it at first, mostly on wi-fi though, but I can't say I have the issue you're describing. There are still some quirks here and there, sometimes it starts lagging or a client will need to disconnect/reconnect to get going, but everything has improved since a few months ago. I also had lots of problems on the original firmware, main reason why I went for OpenWRT with v13. I also have a v10 (I think it's a v10, could be a v9 - unsure atm) and it works much better for sure. Anyway, there may be a conflict with the upgraded components so I advise you to reflash from scratch with the latest snapshot, give it another try afterwards.


#143

Do we have any workaround/solution for this bug?