Archer C7 2.4 GHz wireless dies in 24~48 hours

sammo · 2021-09-24T11:22:19.622Z

Maybe try to disable other capability and test?

hnyman · 2021-09-24T11:46:51.600Z

zen1932:

the two fixes mentioned @amituofo has 'likely' been in 21.02.0,

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.

zen1932 · 2021-09-24T12:10:33.825Z

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.

amituofo · 2021-09-29T16:26:46.412Z

Hello,

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

Overheating
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:

image922×692 212 KB

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:

sys1128×473 12 KB

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

dsouza · 2021-09-29T20:33:32.850Z

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?

jrambo99 · 2021-09-29T20:56:57.517Z

That's a WDR7500 v3?

Untitled-1

61kNxFEtbsL.AC_SX355

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

JonP · 2021-09-29T20:59:48.324Z

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)

JonP · 2021-09-29T21:05:56.588Z

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.

amituofo · 2021-09-30T08:09:47.666Z

Archer C7 2.4 GHz wireless dies in 24~48 hours Network and Wireless Configuration

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?

Archer C7 2.4 GHz wireless dies in 24~48 hours Network and Wireless Configuration

That's a WDR7500 v3? [Untitled-1] [61kNxFEtbsL.AC_SX355] Similar hardware to the C7 v2, 2.4GHZ antennas are external.

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??

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

uweklatt · 2021-10-02T19:51:13.298Z

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

Catfriend1 · 2021-10-02T21:19:36.824Z

Just fyi: I didn't enable soft flow offloading. Against some dropouts on 2.4 G I've found a workaround specific to 802.1x eap-tls (radius driven corporate) wifi that works to keep our mobile phones solidly connected.

option eap_reauth_period '0'

(from my mind of another thread here : Driver cannot safely Rekeying with 801.1x - #11 by Catfriend1 )

JonP · 2021-10-06T06:58:22.605Z

Whole thing crashes, or just the 2.4ghz radio goes down, like the thread topic? Any info in the logs? We need to get some documented info here, for the developers, folks...

I also have never tried the sw flow offload. In a recent test, trying to get some info, I disabled my cron task to reset the wlan1 at 4am. It took a couple weeks before I got the first problem again, then 2days, then again after 3hrs... So, quite a variability.

This with the household load of 22 items and systems connected, varying Zoom call, netflix, youtube, a gamer playing various multiplayer games... that kind of load. As I've stated, I've also tried hammering many 16 up/down flow speed tests and such, without ever provoking an issue, so it seems like some kind of traffic or combination of traffic is the trigger for me. Also remember, I'm using the C7 just as an AP, have an x86 box doing the routing.

If I get motivated, I might try buying some better caps that would be right values and fit the pads, and replace the PS caps. Or, poke around with a 'scope and see if I see any drops on the supply lines, that might warrant changing caps. A bit of time and effort, after I take down the family AP and replace it with something while I test.

Any of you folks have any visible events in the logs when this happens for you?

Also, can you all check with top when you have an event, and see if your C7's have a high system usage like I mentioned seeing, up thread? (high sirq %,low idle time %?)

ruildias · 2021-10-26T18:48:09.337Z

Hello
I have a similar problem with the same chipset (based on athk9) that I could only solve, turning off encryption ... It is now fully stable, even if it is not secure at all (limited to mac address).
I describe it here, maybe some of you can make a try. Here I posted my issue.
Maybe it can give you (the experts) some hints how to proceed.
Thank you!!

ParanoidZoid · 2022-05-05T06:51:00.499Z

Apologies for necroing this thread. However, something interesting got posted into OpenWRT's master branch regarding the chipset used for anyone still using this device. Note the patch notes used a "Yuncore XD3200" for testing. It uses the same CPU as later Archers, such as the C7/A7 (v5) - a QCA 9563 SoC with the 9561 as the ar9003 radio. Integrating this patch will also boost power output and thus, throughput. This may also fix the large number of collisions on 2.4GHz, but I have not tested this yet.

github.com/openwrt/openwrt

mac80211: fix QCA9561 PA bias

committed 04:40AM - 18 Apr 22 UTC

f00b4r0

+47 -0

This patch fixes an invalid TX PA DC bias level on QCA9561, which results in a v…ery low output power and very low throughput as devices are further away from the AP (compared to other 2.4GHz APs), following a suggestion from nbd[1]. This patch has been submitted upstream[2]. [1] https://lore.kernel.org/all/91c58969-c60e-2f41-00ac-737786d435ae@nbd.name [2] https://lore.kernel.org/linux-wireless/20220417145145.1847-1-hacks+kernel@slashdirt.org/ Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>

Joe_90 · 2022-05-05T14:45:11.877Z

I recently "upgraded" my Archer C7 v2 from 15.05.1 (where it was rock solid stable and ran for months without reboot), to 22.02.1 (via 19.x) and the process was pretty much without incident.
However, after about 4 days, I got the issue where 2.4Ghz started to drop its clients. I tried all the tricks mentioned in various threads - daily reboots, ath10k firmware variants, tweaks to the radio settings, but nothing worked. I found that the dropouts happened when my son was streaming video. His PC is at the other side of the house and the 2.4GHz signal is poor (about -76dBm). There was nothing in the system or kernel logs to indicate an issue. Just 2.4GHz clients were dropped and unable to reconnect. No disturbance to 5GHz clients or wired ethernet. I briefly considered trying to go back to 15.05.1, but I thought that the security risks probably outweighed the stability factor.
In the end I re-purposed an old wireless gateway as a 2.4GHz Access Point and disabled its WAN and DHCP settings. I was able to locate it in a more optimal location and connected it via ethernet to the Archer. I then disabled 2.4GHz on the Archer and just run 5GHz and hard-wired connections. It's been stable ever since and my son now has excellent 2.4GHz reception and throughput.

I would echo what many other contributors have said about the 2.4GHz performance on the Archer C7 V2 - it was solid on older versions of WRT but something changed during the LEDE variants which affected stability and this seems to continue right to the present.

anon89577378 · 2022-05-05T20:27:55.304Z

My C7 V2 is pretty solid, and has been from LEDE 17.01 to OpenWrt 21.02

Joe_90 · 2022-05-05T21:23:59.814Z

It may just be something in my environment or use case. When I upgraded to LEDE from 15.05.1 several years ago, I had similar instability on 2.4GHz, so I reverted back at the time. Definitely a software/driver issue triggered by load or some event on 2.4 causing a lockup. In any case, setting up a separate AP for 2.4 has allowed me to disable that particular radio on the C7.

At the moment I have FTTC (Fibre To The Cabinet) which gives me about 66Mb/s on the copper loop from cabinet to the house. Recently, fibre has been installed in the ducting in the street, which will potentially provide a 1Gb/s service offering. At that point I will have to reconsider my whole router setup!

Thanks for your assistance in the sysupgrade process, though. At least the main internet-facing router is up to date and I've learned a few things along the way.

JonP · 2022-05-06T01:46:36.185Z

Yep, agreed on use case may be influential on this one. I've been battling the problem for years... with a home situation with one user in a far bedroom, poor signal, doing a lot of gaming, vid/audio chat, etc. He started classes a while back, and after complaining a lot, a ethernet cable took his traffic off the air. Before that his data habits changed somewhat over that time as well. This also coincided with 20 to 21.xx version updates, trying some master versions, etc, so it's hard to tell if improvements were more due to updates vs traffic changes. Things are currently a lot better, with occasional issues on 2.4 and rare ones on 5.6ghz. No more resetting the wifi radio's every night and still having the problem come up.

You're not the first to report having a "far" station with weak signal in the mix, of people reporting this. Type of traffic could be part of the picture as well.

Joe_90 · 2022-05-06T11:06:35.556Z

Thanks for that feedback. I've seen a lot of your posts on this issue in various threads. The 2.4 drops are a particular pain for me as the house alarm uses wifi and GSM for alerting/monitoring purposes and if wifi drops the key panel starts beeping and I get an alert on my 'phone. If this happens at 2am it's kind of annoying! No 5Ghz option for the alarm, unfortunately. In any case, setting up a separate 2.4 AP has resolved the issue

zen1932 · 2022-05-06T12:00:28.570Z

Several months ago, @sammo found a workaround: disable 'ldpc'.
since I put the following in config/wireless:

config wifi-device 'radio1'
	option ldpc '0'

I never encountered the dying 2.4 Ghz issue.