Archer C7 2.4 GHz wireless dies in 24~48 hours

Hello Pocket_Sevens,

actually I am using ath10k-firmware-qca988x-ct-htt and kmod-ath10k-ct.

Uwe

1 Like

Thanks @uweklatt!

I made some modifications to your script and made it into a function suitable to be placed in System > Startup > Local Startup, ie:

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

### Keep an eye on the 2.4GHz ath9k interface and restart it if no clients are connected
wifi24watchdog() {
  while true ; do
    sleep 60
    grep -q 0 /sys/kernel/debug/ieee80211/phy1/netdev:wlan1/num_mcast_sta
    if [ "$?" -eq "0" ]; then
      /sbin/wifi
      logger wifi24watchdog restarted the 2.4 GHz radio
    fi
  done
}
wifi24watchdog &

exit 0

This also invokes logger so you can keep track of how often this is firing in the System Log.

3 Likes

Hello,

after limiting 2.4GHz to 20MHz bandwidth my Archer C7 v2 runs continously since April 11. without additional scripts or reboots...

Uwe

1 Like

While switching to 20MHz prolonged the inevitable it's not a solution for me, the 2.4GHz dropped twice in the past 4 days.

1 Like

Switching to 20 MHz doesn't work for me. I also tried all combinations of firmware and kernel modules for 5 GHz. I have latest stable LuCI 19.07.

I'm also posting testing procedure, so anyone can reproduce this problem. You can use iperf on 2,4 GHz SSID and it will fail in hours.

  1. open ssh to router
    opkg update
    opkg install iperf3
    iperf3 -s

  2. download iperf client on PC - https://iperf.fr/iperf-download.php
    connect to 2,4 GHz SSID
    iperf3.exe -c 192.168.1.1 -t 86400 (change IP to your router IP)
    the connection will fail after 1-3 hours

2 Likes

Used to experience something similar... Not sure what I've done or not done, or what the neighbourhood has been doing, but the below config on 19.07.2 has seen me through a month of run time without any problem:

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11g'
        option htmode 'HT40'
        option legacy_rates '0'
        option channel '1'
        option path 'platform/ahb/18100000.wmac'

config wifi-iface 'wifinet1'
        option network 'lan'
        option ssid '***ssid***'
        option device 'radio1'
        option mode 'ap'
        option key '***key***'
        option encryption 'sae-mixed'
        option wpa_disable_eapol_key_retries '1'
        option ieee80211w '2'

For 5GHz, the non-CT version of firmware and drivers are being used.

Cheers.

1 Like

It works ok for months and then fail 5 times in a week. It all depends on traffic. Higher the traffic, sooner it will fail.

Can you run the ipref method to simulate the traffic on 2,4 GHz?

Hi Primoz,

I have checked the connection with iperf3 as you said.
(Connection from WINDOWS pc to Archer C7 v2).

Runnning now 2.4GHz for more than 2 hours without problems (transferred 88 GBytes).

Uwe

Can you post your build versions. I can test it on mine.

SSH to router and run: opkg list-installed |grep "9k|10k"

I have:
OpenWrt 19.07.2, r10947-65030d81f3
kmod-ath9k - 4.14.171+4.19.98-1-1
kmod-ath9k-common - 4.14.171+4.19.98-1-1
ath10k-firmware-qca988x-ct-htt - 2019-10-03-d622d160-1
kmod-ath10k-ct-smallbuffers - 4.14.171+2019-09-09-5e8cd86f-1

Edit:

Were you still running this script during test? Please disable it during the test. It is a solution, but not for me, because I have 0 clients many times in normal operation.

Hi Primoz,

I use similar drivers (only kmod-ath10k is different):

OpenWrt 19.07.2 r10947-65030d81f3 / LuCI openwrt-19.07 branch git-20.113.40463-d6c07c8
ath10k-firmware-qca988x-ct-htt - 2019-10-03-d622d160-1
kmod-ath10k-ct - 4.14.171+2019-09-09-5e8cd86f-1
kmod-ath9k - 4.14.171+4.19.98-1-1
kmod-ath9k-common - 4.14.171+4.19.98-1-1

I have switched off all "reboot" and "restart" scripts.

My

wifi-config

config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option beacon_int '100'
option legacy_rates '0'
option noscan '1'
option country 'DE'
option path 'pci0000:00/0000:00:00.0'
option htmode 'VHT80'
option txpower '23'
option channel '44'

config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option ssid 'xxxxxxxxxxx'
option key 'xxxxxxxxxxxx'
option encryption 'psk2+ccmp'
option network 'lan'
option disassoc_low_ack '0'
option wds '1'

config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/ahb/18100000.wmac'
option hwmode '11g'
option legacy_rates '0'
option noscan '1'
option country 'DE'
option txpower '20'
option htmode 'HT20'
option channel '11'

config wifi-iface 'wifinet1'
option network 'lan'
option wds '1'
option ssid 'xxxxxxxxxxxxxx'
option encryption 'psk2'
option device 'radio1'
option mode 'ap'
option wpa_disable_eapol_key_retries '1'
option key 'xxxxxxxxxxxxxx'
option disassoc_low_ack '0'

config wifi-iface 'wifinet2'
option wds '1'
option ssid 'GAST'
option encryption 'psk2'
option device 'radio1'
option isolate '1'
option key 'xxxxxxxxxxxxxxx'
option mode 'ap'
option network 'gast'
option wpa_disable_eapol_key_retries '1'
option disassoc_low_ack '0'

Uwe

While you casually research you can throw a script to bounce your rig every night. I do mine at 3am and have no issues.

1 Like

I tried all your settings without any success.

Then I tried to move the notebook closer to the router and it worked fine. I suspect the bug has to do something with high bandwidth and large number of retransmission due to lower signal quality. I don't have any experience with debugging this kind of problem, but I can test it if anyone finds a solution.

Ipref3 on 2,4 GHz with 20 MHz channel gives me:

  1. near router with around 40 mbit/s: didn't fail in 5 hours
  2. next room with around 15-20 mbit/s: fails in 1 hour
1 Like

^^^ this is an important setting, it added greater 2.4 stability on both an MT76 (19.07.3) and a C7 (18.06.4) units.
Seems the rekeying process is buggy, and borks the stack once it goes off the rails once.

In what file is this setting found?

It is in /etc/config/wireless
See example in prior post I was replying to:

1 Like

In LuCI it's under Network -> Wireless -> Edit -> Wireless Security -> Enable key reinstallation (KRACK) countermeasures.

Cheers.

1 Like

Good to see that SOMEONE(s) is still working on this!

My behavior is a bit different, its every few days the 2.4ghz radio goes unresponsive, little to no indication in the logs, but almost always recovers on its own. I get the occasional kernel warning from ath10k, as well, but dont seem to see loss of service on 5ghz

Edit: was mistaken about the KRACK being missing from snapshot, it was the management frame protection stuff. I'll try turning off the KRACK stuff, always have enabled it in recent years.

A thought, now that theres more than a few C7 users here, what version, and maybe more importantly what chip versions, do you have? I have an odd "V3" which dosent match the pics on the hardware site. It uses the external antennas on 2.4 and 5ghz, no internal 2.4 antennas. Anyway. My SOC (main processor and ath9k radio) is a QCA9558 ver 1 rev 0.

I dont know how to get the ath10k radio HW info. It dosent show up in the klog like the SOC info. Anyone know a command to bring that up? Maybe radio versions will be a clue.

Just had an outage while typing, and in the middle of wifes company meeting...though this time it was the WAN eth in my separate router dropping, not my C7 AP! Wholly different problem, but how many times might I have mistakenly thought it was the wifi issue? Well, another issue to chase...

Btw, I'm testing now latest DD-WRT to see if this problem is existing there as well. So far, I'm getting other issues but since 24hours it looks more stable to me then Openwrt.

Let us know what happens. What versions of ath9k and ath10k modules and firmware are they using?

Also, anyone come back wirh their hardware chips, to see if we are a batch of different, or mostly the same? Anyone reading this and NOT having radio problems please check and reply.

1 Like

Too late to check myself, I had to switch back yesterday midnight as some devices have got troubles, eg. Samsung S9+ reporting "Access point is full", another device OnePlus Two getting disconnected each 15min or so etc. The true is that some other devices in the opposite were even more stable and the wifi didn'd die like in case of Openwrt.

But anyone can give a try himself, I switched to and back even directly between dd-wrt to openwrt without stock firmware.
https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2020/06-15-2020-r43420/tplink_archer-c7-v2/

How to :