Archer C7 V2 - Massive Problems

Placebo effect?

Different wireless hardware, different driver - ath10k isn't involved with the 2.4 GHz radio at all.
If you had problems with the 5 GHz radio, switching to a different firmware might help, but not for 2.4 GHz.

I am currently using "backdated" ath10k and running same sort of "test" on 2.4GHz...if it keels over (which it should withing 1 day) we will know for sure.

P.S.

According to this thread, ath10k-firmware seems to affect 2.4GHz as well:

The interaction could be out of memory because the -ct ath10k uses a lot of RAM. There is now -ct-smallbuffers which must be used on devices with 64 MB of RAM and might help on a C7 even though those have 128 MB of RAM.

Either ath10k-ct kernel module can be used with the same ath10k-firmware-ct. The ath10k firmware runs on a CPU core inside the 5 GHz WiFi chip, it has no connection to the main CPU and 2.4 GHz WiFi.

host-target communication is bidirectional and a bogus firmware value returned from the 5ghz core can screw up things in main cpu core

Is it possible to use kmod-ath10k-ct-smallbuffers with ath10k-firmware-qca988x?

For best results a ct kmod should be used with a ct firmware. At the least there will be lots of error messages if not matched.

Ok, but non-ct firmware has higher throughput...

1 Like

3 days later and 2.4GHz is chugging along quite nicely. It should not work but it works...fitting backdated ath10k firmware fixes 2.4GHz stability. Go figure.

1 Like

Me too :wink: whyever it fixes problems

Update: switching ath10k drivers does not fix 2.4 issues :frowning: Five days later, 2.4 keeled over. Some clients just stopped responding (but were still associated), new clients could connect but not surf. Two hours later, new clients could connect and surf but old (that were already connected) could not.

Any other hints on how to troubleshoot? Can something be done with ath9k drivers?

Tried ct-smallbuffers?

No, but I tried -ct, non-ct and backdated firmware version. It takes couple of days for issue to manifest itself so it is very cumbersome testing. I am getting somewhat sceptical that you can fix 2.4 radio issue by swapping different 5GHz drivers ... it did not work with three different drivers.

And it is sneaky issue...it appears to work but will start dropping packets or doing some other nasty stuff after couple of days, if subjected to enough load.

At the same time, AR5BXB92 in x86 router running OpenWRT just keeps on chugging with same client load, month after month.

Wat do I do :frowning:

Is this better with 19.07.2? Do you still require to switch to non-ct drivers?

That works for me.

1 Like

Updated to the snapshot.

Well i installed the latest snapshot https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin

also:
opkg update
opkg install luci

to get the GUI back

Still disconnecting.... but not as often? i think?

Yes disconnecting is back.
Nothing was fixed.

This is bullshit

1 Like

It fixes it self after restrating btw

before:

Request timed out.
Request timed out.
Reply from 192.168.1.1: bytes=32 time=82ms TTL=64
Reply from 192.168.1.1: bytes=32 time=65ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.1.1: bytes=32 time=30ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=30ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=85ms TTL=64
Reply from 192.168.1.1: bytes=32 time=161ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=29ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.1.1: bytes=32 time=59ms TTL=64
Reply from 192.168.1.1: bytes=32 time=135ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=205ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=163ms TTL=64
Reply from 192.168.1.1: bytes=32 time=162ms TTL=64
Reply from 192.168.1.1: bytes=32 time=40ms TTL=64
Reply from 192.168.1.1: bytes=32 time=7ms TTL=64

Ping statistics for 192.168.1.1:
    Packets: Sent = 1887, Received = 1203, Lost = 684 (36% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 1021ms, Average = 108ms

After:

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=6ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=6ms TTL=64
Reply from 192.168.1.1: bytes=32 time=36ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64

Ping statistics for 192.168.1.1:
    Packets: Sent = 19, Received = 19, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 36ms, Average = 4ms

Hi what are you saying fixed it for you?