Archer C7 2.4 GHz wireless dies in 24~48 hours

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

So the two fixes mentioned @amituofo has 'likely' been in 21.02.0, if this is the case, then the fixes do not fix this '2.4Ghz dies' issue.

1 Like

Maybe try to disable other capability and test?

2 Likes

The first "fix" is from "gluon" private repo... not from Linux kernel.

The second is from Linux. We use backports-5.10.42 in 21.02.0,
so if that fix is in Linux 5.10.42, we have it.

1 Like

Anyway, I don't think the first fix is related to our 2.4Ghz issue, since a simple scan brings the 2.4GHz back to life.

1 Like

Hello,

has anyone consider the possibility of hardware faults in the 9558 SOC due to:

  1. Overheating
  2. Dried out electrolytic capacitors in the power circuit

Either individually, or a combination of both causes subtle hardware faults in SOC that have not been properly recovered.

The symptoms reported by fellow users above, i.e. stress testing with iperf, heavy gaming traffic, multiple SSIDs and numerous connected clients, etc, can all be explained by the above causes.

There is also evidence to prove my point:

As you can see, there are a few modifications to my C7v2, mainly being the heat sinks, and upgraded polymer capacitors in the power circuit.

My uptime now is 5 days with 20Mhz width, fixed channel and testing with over 20Gs of iperf when 4 clients are connected to the 2.4G wireless:

I suggest adding a heat sink to the SOC, and preferably the peripheral chips as an immediate remedy.

Please feel free to share what you think, and report back if the heat sinks help.

With Metta

1 Like

Interesting. My C7 v2 has three detachable antennas on the rear side. Per your picture, yours seems to have only two non-detachable antennas on the rear. Is your C7 v2 a different variants from the standard C7v2?

That's a WDR7500 v3?

Untitled-1

61kNxFEtbsL.AC_SX355

Similar hardware to the C7 v2, 2.4GHZ antennas are external.

1 Like

Hmmm, looks like you added another set? That wasn't a v2, was it, or did you put in in another base for 6 antennas?

Anyway, caps drying out (depending on the crappiness of your original caps) tends to take many years to decades... I'd wonder if they should be bad yet. Then again, had a TV that had had a bad run of caps, and people would fix them by replacement.

Also, had been hearing about people overclocking the SOC from 720 to 1ghz.. and maybe not adding a heat sink? (ah, but one was complaining a lot in regards to 2.4ghz not working) If people are doing that w/o heatsinks, it's probably not a heating issue. OTOH, which version do you have? I have had a v2 and v3, currently use the v3, and it has a large number of heatsinks that the v2 didn't have.

At the moment, mine has gone 5days plus, without having an issue, while I was waiting for one to log data, and then 4-5hrs after the reset had another event... I also have tried marathon speedtest sessions to load it and have never had it lock up during those, so it feels like a condition of traffic type or some such is needed to set it off. So, it seems like just loading and heating are less likely.

Wondering what everyone sees in their logs when this happens. Looking at the klog and syslogs, I don't see anything in my klog, the syslog will be reporting things like group key handshakes and connecting and disconnecting devices. When a dropout happens, all I can see is a failure of all my wlan1 devices on the group key handshake, and they all disconnect right after. That's it. Doing a device reset, it wakes up, they all log in and back to normal.

The other odd thing I noticed recently was during a wlan1 outage there was an unusually large amount of load.
Looking at the system with top, high (35%) sirq, low idle time (20-30%), and ksoftirqd taking 12% or so of cpu. This is heavy, more like a in the middle of a speedtest kind of load.

After I reset the radio, it dropped back to 80% or more idle time, 2-4% sirq, which is what I'd expect out of the 2-300kbps light load in the house that was happening at the time. (load all on 5ghz radio, and after the 2.4 picked up the 8-9 clients it normally runs)

1 Like

Hmmm... another wierd critter. I have a C7 v2 (maybe hopelessly bricked) it has the 3 external antennas which are 5ghz only, and 3 2.4ghz internal bent metal antennas. I got a "v3" later, (US not Taiwan) which only had 3 external antennas, for both 2.4 and 5ghz. It has some kind of diplexer on the 5ghz slotted radio card, the 2.4 radio coaxes plug in there and only one set of coaxes go out to the antennas.

Amtuofo's pic of his, shows the 5ghz radio on the main board, rather than in a separate plugin card with socket on the main board like both of mine. Lot of variations on this "model" over time, it seems.

1 Like

Hello fellows,

yes, the picture is not a U.S/EU market type of C7v2, it is a mainland China version of the C7v2.

Long story short, it is essentially the same hardware, with typical low cost components, especially true in the manufacturer's home market who skims even more on part quality.(This is also why in China router enthusiasts actively avoid tp due to their business practices, this should be reserved for another topic)

Substandard components, used in a circuit board designed for cost cutting with little to no engineering tolerances, under circumstances of heavy data traffic with SOC overheating and large power surges thru half dried electrolytes, what can we expect?? :thinking: :unamused:

Of course this is no conclusion, unless we can do some rigorous lab testings.

Or we can slab on some heat sinks and see they work.

With Metta

2 Likes

Hello,

I found an interesting effect:

When I disable "software flow offloading" my C7v2 2.4 GHz works since 20 days rock stable.
I use 19.07.8 with non ct-drivers, mesh and two SSIDs.

When I enable "software flow offloading", it crahes after some time (hours).

Uwe

3 Likes