TL-WR841N v13 WiFi not stable?



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.




I build from master by git pull + update feeds.

Perhaps I'm missing something? Checking 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?


Hello @tatel


You can check the latest Openwrt commits on GitHub.

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

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:
So i modify my MakeFile to:


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.



@ 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


Hello @tatel




OK, now I see it.

Thank you again


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


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 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 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 hostapd: wlan0: STA 44:6e:e5:36:59:37 IEEE 802.11: disassociated due to inactivity
Thu Aug 16 08:04:28 2018 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.


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



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.



@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?




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

This is the direct link to the master branch.




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.



Felix Fietkau has been doing most of the driver updates to make mt76 functional. You can see the mt76 development commits at:

Felix then periodically merges those into the snapshot branch, which you can see in this filter link

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



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.


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


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)


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 ( 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 ( 56 data bytes
64 bytes from 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 icmp_seq=27 ttl=49 time=1007.432 ms
64 bytes from icmp_seq=28 ttl=49 time=42.376 ms
64 bytes from icmp_seq=29 ttl=49 time=44.239 ms
64 bytes from icmp_seq=30 ttl=49 time=41.850 ms
64 bytes from icmp_seq=31 ttl=49 time=41.768 ms
64 bytes from icmp_seq=32 ttl=49 time=42.523 ms
64 bytes from icmp_seq=33 ttl=49 time=42.752 ms
64 bytes from icmp_seq=34 ttl=49 time=43.078 ms
64 bytes from icmp_seq=35 ttl=49 time=42.775 ms
64 bytes from 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


@Santosh check the bug reports for the mt76 driver.


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


Do we have any workaround/solution for this bug?