TL-WR841N v8 ath79 link unstable

This exact same thing happens for me on a GL.iNet AR150 as well.

What's the suggested way to deal with it? Changing to 19.07 ath71xx?

Which OpenWrt image have you flashed? Please provide the link to the image.

The issue is the same as OP's. Intermittent WAN connection drops which show

eth1: link up (10Mbps/Half duplex)
eth1: link up (100Mbps/Full duplex)

in dmesg, but nothing with logread. This router has been running for years with 18.06 ath71xx and 17.01 ath71xx, and has never showed this issue ever before.

It also seems to be limited to this switch, because I have a bunch of TL-WDR4300's as well, with a different switch but the same SoC, and they do not have any issues on ath79.

I'm running 19.07 with the old switch driver without any issues but you'd need to build the image yourself then

BusyBox v1.30.1 () built-in shell (ash)

u  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 OpenWrt 19.07.0, r10860-a3ffeb413b
root@OpenWrt:~# uptime
 11:35:36 up 7 days, 12:25,  load average: 0.65, 0.25, 0.12

I have installed 19.07 ar71xx now. It has been stable for two days. No connection drops, nothing in dmesg showing any link changes.

I have same issue on TL-WR842N v3. Could you tell me please how to use old switch driver?

Use the ar71xx build!

I can confirm the issue on TL-WR842N v3 under 19.07.1 ath79 build. Reverting back to ar7xxx/ar9xxx target resolves it.

Hello, I can confirm that the problem which Crect originally described exists on a AVM Fritz!Box 4020 with ath79 (using this image: and does not exist on the same device with ar71xx (using this:

I met the issue (eth1 link down up) with device gl-ar300m-nand.
I build my firmware on branch master with commit 3d93b35f03 and 443fc9ac35 reverted. The issue resolved.

1 Like

Thank you @zhanhb. I had the same issue with WAN link going down on GL-AR300M and building on master with 3d93b35f03 and 443fc9ac35 reverted helped me too.

Hi! Here are two commits addressing differences I found between the two drivers:

I'm unable to reproduce this issue with my routers so I can't test whether these two commits are effective.

Update: Nope. I also got this issue after running my router for several hours and the two commits above don't fix anything :frowning:

1 Like

Here and here also with very similar problems. I can't maintain an SSH connection even for a few minutes due to the constant fall of the WAN interface :face_with_symbols_over_mouth::face_with_symbols_over_mouth::face_with_symbols_over_mouth:

I'm having the same issue. I'm currently trying the master branch building - no idea how to do that, doing my research - and will report back.

Do I need to rollback using git or does the master branch already have that reversion applied? Sorry about the noob question.

These two commits are commit to both branch 19.06 and master. You can revert it with

You can download the rom I build (master branch) on page With some customize patches(

I confirm this. It is a bug from these two commits.
Just do:
git revert 3d93b35f03 443fc9ac35
and compile again.
Working like a charm. I tested totolink RH 300 version 4 which is QCA9533 chip.

1 Like

Does it work in 19.07.4?

All latest openwrt builds with the new switch are buggy. It will disconnect eth1 and will do it more frequently on more traffic.
This patch:

and this one:

not okay.
Just revert them and compile as normally.
Switch driver ag71xx is still better :slight_smile:
No need to switch off from ath79 target !
1 Like

Since 21-09 seems like this is fixed right? Version 19.07.05 and this commit:
Found it following the bug link provided by this post

Chuanhong Guo commented on
21.09.2020 07:14
Here's a fix for this:

It is still not okay. Mac addresses of the devices are swapped.
Something like GMAC0 and GMAC1 changed.
ETH1 or WAN should always be 1 number above ETH0/switch address.