TP-Link Archer C7 v2, OpenWrt 18.06.4 r7808-ef686b7292
Every 24~48 hours on the 2.4 GHz WiFi, network starts to crawl, has high ping times and then just dies. It may come back but most of the time it stays dead. A router reboot fixes it for another day. Ethernet connections are fine. There is no time of the day or particular sites that do this. How do I debug the issue?
Look at the logs prior to rebooting.
I do not see anything unusual entries in the kernel log as well as system log. Can you please specify more? Can I increase log level for WiFi?
Here are few last lines from the log before rebooting. guest and otnet are the two vlans served by this physical radio and two logical wifi networks respectively.
14.676009] urandom_read: 5 callbacks suppressed
[ 14.676016] random: jshn: uninitialized urandom read (4 bytes read)
[ 23.495443] eth1: link up (1000Mbps/Full duplex)
[ 23.500203] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 23.539768] br-guest: port 1(eth1.3) entered blocking state
[ 23.545556] br-guest: port 1(eth1.3) entered disabled state
[ 23.551636] device eth1.3 entered promiscuous mode
[ 23.556538] device eth1 entered promiscuous mode
[ 23.637509] br-guest: port 1(eth1.3) entered blocking state
[ 23.643296] br-guest: port 1(eth1.3) entered forwarding state
[ 23.649337] IPv6: ADDRCONF(NETDEV_UP): br-guest: link is not ready
[ 23.917234] br-lan: port 1(eth1.1) entered blocking state
[ 23.922758] br-lan: port 1(eth1.1) entered disabled state
[ 23.928558] device eth1.1 entered promiscuous mode
[ 23.980417] br-lan: port 1(eth1.1) entered blocking state
[ 23.985942] br-lan: port 1(eth1.1) entered forwarding state
[ 24.320011] br-otnet: port 1(eth1.4) entered blocking state
[ 24.325536] br-otnet: port 1(eth1.4) entered disabled state
[ 24.366187] device eth1.4 entered promiscuous mode
[ 24.380801] br-otnet: port 1(eth1.4) entered blocking state
[ 24.386326] br-otnet: port 1(eth1.4) entered forwarding state
[ 24.528497] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 24.534512] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 24.566865] IPv6: ADDRCONF(NETDEV_CHANGE): br-guest: link becomes ready
[ 24.586777] IPv6: ADDRCONF(NETDEV_UP): eth0.2: link is not ready
[ 25.574413] eth0: link up (1000Mbps/Full duplex)
[ 25.579237] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 25.656038] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.2: link becomes ready
[ 30.329415] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 30.556259] br-guest: port 2(wlan1) entered blocking state
[ 30.561917] br-guest: port 2(wlan1) entered disabled state
[ 30.567953] device wlan1 entered promiscuous mode
[ 37.886265] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 37.892894] br-guest: port 2(wlan1) entered blocking state
[ 37.898560] br-guest: port 2(wlan1) entered forwarding state
[ 37.922841] br-otnet: port 2(wlan1-1) entered blocking state
[ 37.928415] br-otnet: port 2(wlan1-1) entered disabled state
[ 37.934425] device wlan1-1 entered promiscuous mode
[ 37.946433] IPv6: ADDRCONF(NETDEV_UP): wlan1-1: link is not ready
[ 37.952754] br-otnet: port 2(wlan1-1) entered blocking state
[ 37.958325] br-otnet: port 2(wlan1-1) entered forwarding state
[ 38.361482] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1-1: link becomes ready
[ 50.553712] random: crng init done
I don't have loglines yet to neatly contribute here, but I just wanted to add that my router (tp-link archer c7 v2) is experiencing connection outages as well, since the recent upgrade from 18.06.r1 to r4.
18.06.r1 had been running stable for at least half a year or so.
R2 is running stable on a different router (same model), so I suspect a change between r2 and r4 is detrimental to this router. From the changelog nothing jumped out.
Phenomenon:
Wifi is still connected but dns is out. When connecting via ssh, sometimes I have to reconnect before I can actually use the terminal.
Happens every few days (3 times since upgrade).
This could well depend on local WiFi context, if you have a congested 2.4 network, then the default 'back-off' of signal strength on a channel with multiple competing APs will result in loss of working connectivity.
Try scanning for the least congested channel, then manually configure the AP to that channel, and also lock in the signal strength to a value that woks in your context. Max is not always best, as it just causes more headaches for all, best limit your strength to the coverage you need.
I've seen this since 17.01.x on various models of the C7. Guessing that the back-off values and/or algorithm get regularly tweaked, so plausible that the various build behave differently. Then again, could be something else.
Not an expert at all, but it really sounds like what my TL-1043ND v3 had. You might want to try what I described at the beginning of this post.
@jul059 I will try the wireless tweak that you mentioned. Where do I change those settings? I also noticed another portion of your post that talks about LAN traffic slowing down. I see the same issue. The Internet to WiFi performance crawls on PC 1 when I am moving large files on the C7 Ethernet switch between PC 2 and PC 3. Is this related?
@TopDog, You are correct, I do not have a free non overlapping channel in the neighborhood but I have scanned and set up a channel that is least populated and lowest signal power, and used one digit off that channel that is not being used by anybody. My power setting is default.
For the hardware ACK, I went in etc/modules.d/ath9k and changed the command to "ath9k nohwcrypt=1" instead of simply "ath9k". You will need to login with an ssh client and use an editor to edit, I simply used vi. For the adaptive noise immunity, again through ssh, the following command does the trick on 18.06.4: "echo 0 >/sys/kernel/debug/ieee80211/phy0/ath9k/ani"
This might all be dependent on your particular hardware, and they won't work if it's not using the ath9k driver. You will have to double-check that.
Concerning The LAN switch, I can't say if you specific chip is affected in the same way, but's entirely possible. I think this might have been solved in the development release with better usage of hardware offloading, but I'm waiting for a stable version to test it out as it's not a dealbreaker for me for this specific router.
In case you want to test the latest development version with the new ath79, here's your image.
If it solves all your problems, which I think it might, especially for the LAN switching speed, it might be worth it to wait for the stable release instead of endlessly fiddling with settings and configuration with the 18 branch.
@ metric
Hi, I am experiencing the same issues you have been experiencing. Wifi works for about ±24 hours, after that it's unstable and that results in high packet loss. I have two TP-Link Archer C7 V2's with both the same problems.
Did the solutions provided here work for you?
I'm in the same boat too. I have 3 of these variants, two Archer C7 v2 units, and one Archer A7 v5. The C7's are running 18.06.4, and the A7 is running snapshot r11025-14054e2982 / LuCI Master (git-19.257.56672-2e20686). They're spread across the 3 discrete 2.4 GHz US channels (1,6,11).
I see stable operation after a fresh reboot, but after about a day or two, performance degrades. Symptoms are lost packets with slow and unreliable communications, sometimes to the point that the client(s) have no IP connectivity, but I can still see them connected in the list of wireless clients with good/great TX/RX rates. If I reboot the client devices and reconnect them to the same AP, the problem remains. If I restart the wireless interface(s) on the AP, the problems remain. If I reboot the AP, the problem goes away for another ~12-24 hours.
System and kernel logs show nothing that looks odd, at least to my eye. CPU/load on the system looks normal.
If you lock in channel and power, does the problem still persist?
How congested is your wifi environment?
Per my post above, I believe the default wifi back-off is way too agressive, and it goes to low-power way to quickly. Does anyone know where that back-off algo is and what values it depends on?
Commercial routers don't seem to have that issue. Maybe they suppress the back-off or have very high thresholds.
Hi, I am using a fixed power level and fixed channel. This was one of the first things I have tried.
I think a scheduled reboot will solve it for now.
I believe that my problem is with the amount of data transferred on WiFi. If large data is transferred at high rate (gaming) the router dies. BTW normal IoT stuff on WifFi and streaming videos on Ethernet works fine for days. It is just the WiFi and gaming together is problematic. Currently reboot on cron is my solution till next version comes out.
I have installed the latest version of Lede and the problem seems to be solved now. Running for at least one week now. I have also tried OpenWrt 19.07 but had the same issues as 18.04.
Which version are you using? I cant tell what you mean by "the latest version"?
I am using LEDE Reboot 17.01.6.
I have encountered similar issues with nightly build, even blamed the driver once.
Last time it happened after an update, by calling WiFi down and up again makes it never down anymore.
I was using ssh shell with corresponding commands:
/sbin/wifi down/sbin/wifi upThanks for the tip! I'm giving LEDE a shot. Won't help me much with my A7 v5, but if it works on the C7 v2's, I might take a swag at backporting A7 support to LEDE.
TopDog, I should have responded to you specifically as well...
My channel and power were locked.
How congested? I'm not sure how to quantify that. In terms of other SSIDs on the same channels, not a lot. I live in a residential neighborhood with quarter acre lots where the neighbors' SSIDs don't bleed too far into my own house, and there are few visible SSIDs. As stated, I am using 1,6, and 11 amongst all my APs, and each of them exhibited the same issue.
I disabled ANI, applied the hardware ack (ath9k nohwcrypt=1) change, as well as disabling low ACK disconnects with no appreciable improvement. I also tried using the ath10k ct-htt drivers, though I don't think those apply to the 2.4Ghz radio.
If I could, I'd love to try the ar71xx images on the A7. I suspect this is something unique to the newer ath79 drivers.