Archer C7 2.4 GHz wireless dies in 24~48 hours

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

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 )

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

1 Like

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!! :slightly_smiling_face:

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.

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.

2 Likes

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

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.

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.

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

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.

3 Likes

Hmmm, I believe I tried that with no benefit. Either that or my C7 did not have the option.

Reading back in this thread, I see I did not find that as an option to set, and I think I wasn't able to apply it and have it stick.

Also, it seemed Sammo didn't have a C7, and his chip was not the same one, just "in the family". And, uh, you were saying that you tried it, and it didn't work for you. Did something change along the way?

802.11n -

802.11ac -

It's an available option on the C7 V2.

I have 3 wdr7500s with flash size modified to 16MB, I run C7V2 firmware.

Before disabling 'ldpc' option, I had been having dying 2.4GHz issue, no matter with -ct or non-ct 5Ghz driver.

But since I disabled the 'ldpc' option in 2.4Ghz, no more dying issue, no more need to scan in cron.

So my case is for C7V2.

oh, it did not work at first try because I forgot to remove the 'txq limit' workaround, after removal, it worked.

1 Like

Ok - good to know that you are running C7 V2 firmware and having success with that setting. I did see @sammo's posts in another thread regarding 'ldpc', but I thought the hardware/firmware was slightly different, so I didn't actually try that particular tweak. At the moment, I actually have way better 2.4GHz coverage in the house using a separate AP located in another room which is connected back to the Archer by ethernet.

1 Like

Well... I might disagree with you that you have a "C7V2" case there, if your hardware is different, even if it runs with the C7V2 firmware.

Looking back in this thread, when this came up, I found that ldpc was not in my config, and IIRC, I couldn't make it take it. I have a real C7 v2.

I'd like to see if any other C7 v2 folks (or other "real" C7 versions) actually have that in their configs, or are able to add the command.