Archer C7 2.4 GHz wireless dies in 24~48 hours

Catfriend1, did you ever try the shorter memory change? Though I'd understand if it seemed to fix it, you would have just kept using the larger change... :wink:

Agreed, hence I have limited the scan to 1 off channel shortest delay. I don't like the workaround and hence came up with the txq memory and did further investigation.
For me the txq memory increase/decrease does not work. Disable/enable ani periodic does not work.

From you previous message.

Many seem to not know/remember that back when in the 16.x.x.x and partly into 17.x.x.x era, C7's were rock stable, and my uptimes were determined by power failure or the next release coming out. Solid 2.4ghz/ath9k performance. Bug reports had been filed, somehow it slipped thru the cracks.

I had a look at the WiFi config generated before/after 16.x/17.x and currently testing with a certain WiFi chipset feature disabled and it's holding up. Pure AP brute force iperf over 1 day. On AP/STA doesn't even loss beacon or disconnect

2 Likes

I also ran with defaults before setting txq mem limit higher (non ct) , was stable but sometimes laggy on high load withany devices. I cannot use ct drivers as they don't provide wpa3-sae + 802.11s mesh for my batman setup.

I had a look at the WiFi config generated before/after 16.x/17.x and currently testing with a certain WiFi chipset feature disabled and it's holding up. Pure AP brute force iperf over 1 day. On AP/STA doesn't even loss beacon or disconnect

sammo, how is it holding up now.. if still good, what feature did you disable?

1 Like

little off-topic question, what's your ping times on the AP wirelessly? is there any jitter (deviation)?

edit: don't mind me. it was the phone, testing with laptop there's no jitter whatsoever. something in phone's radio or wireless client software causes jitter between phone and the AP. (I'm thinking maybe idle mode for power saving causes this or keep alive frames are not adjusted... but even in dev. mode there are no corresponding setting in my galaxy s9)

@sammo, is this working well? What is the change you made?

gl inet ar300m with QCA9531, @650MHz SoC on 21.02 is now running stable on 2.4Ghz.

run below command to check if [LDPC] exists on the ht_capab line for the 2.4GHz file

root@repeater:~# grep ht_ca /tmp/run/hostapd-phy*.conf
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]

disable this if exists /etc/config/wireless, make sure its the 2.4Ghz section

config wifi-device  radio0
        option type     mac80211
        option channel 11
        option hwmode '11g'
        option path 'platform/ahb/18100000.wmac'
        option country 'GB'
        option htmode   HT20
        option legacy_rates 0
        option ldpc '0'

reboot, and rerun, ensure LDPC is removed.

root@repeater:~# grep ht_ca /tmp/run/hostapd-phy*.conf
ht_capab=[SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]

I hope it works for your tplink C7. Dont forget to remove any previous workaround.

3 Likes

Great, thanks! I'll try this soon. Out of interest, what led you to finding out that removing LDPC helped?

It seems LDPC was introduced as an optional error-correcting scheme along with 802.11n. I guess it's OK to run a HT AP (e.g. 2x2 40MHz 300mbit) with only BCC, though LDPC should be better at symbol error recovery (noise rejection).

Presuming there isn't a LDPC hardware bug in ath9k-era chipsets, I'd be hopeful that some 2017-2018 era commit to the ath9k driver can be found as a root cause.

1 Like

I've also have a tplink 703n (limited shelf life) which has an ar9331 chipset which runs stable.
Looking up the table below and abit guess work (Tx/Rx affects performance, depending on spatial stream)

Sammo, I see LDPC listed on my C7 in the capabilities, but there is no mention of it as an option in the /etc/config/wireless for the 2.4ghz radio. So it would seem to not be switchable, or at least that way This is on 19.07.7

Did you try this on a C7? You mention a GL AR300m, but that's a different router with a different QCA chip than the C7 uses. Did you have a similar problem on that router and this fixed it?

1 Like

I don't have a tplink c7. GL AR300m uses the same family of athoros chipset exhibit the same problem. Slowness during heavy traffic or simulated with iperf. Check the link 3/4 down the page for wireless capability configuration. Let me know if it works on the C7

I will try later to see if I add that option set that isn't currently in there, that will be able to set it to off.

Have you heard that other routers using the QCA95xx family chips also have this problem? I haven't been hearing about 2.4ghz dropout like many have been complaining of on C7's over the past few years.

What other symptoms did you observe on your router? Your issues sound different than what we experience on C7's, with their different chipset. If yours just "slows down", I'm wondering if it's the same issue...

Hello fellas,

is this still a bug today? After some digging, this should have been resolved as of now, please see:

And:

If anyone could verify this in their source, and compiled firmware, much appreciated!

With Metta
:pray:

Were those commits part of 21.02.0 stable?

Hello Catfriend1, this was the question.

If any developer or fellow user could verify these commits have been applied to the stable releases, and have been effective.

:pray:

Hello,

a quick search of openwrt git show that the above fixes have not been applied, can anyone help??

https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=HEAD&st=commit&s=ath9k

:pray: :pray:

1 Like

@amituofo I think it's best you contact openwrt devs e.g. @hnyman @tmomas . Maybe they could plan a 21.02.1 ...

We take the mac80211 wifi drivers directly from Linux kernel via backports. That commit is likely part of the source fetched from there, as that commit has been in the Linux repo since 2019.

1 Like

@dspalu32 , @Sunspark, @JonP

Any early adopter confirm removal ldpc works on the C7?

1 Like

Unfortunate for me, for my C7V2 running 21.02.0, 2.4GHz still dies with removal of ldpc, but I realized that I did not remove the 'extending txq memory' workaround.

I am testing without 'extending txq memory' but I am afraid that txq memory size should not interfere ldpc.

1 Like