Archer C7 2.4 GHz wireless dies in 24~48 hours

@sammo: Just to understand your findings better, I've got those event 84 on wlan0 (5 GHz radio) but they occur rarely. Does that mean my AP got - according to your findings - instable already or does that have nothing to say because it's not the 2.4 GHz radio which sent the event?

@Catfriend1

I'm not sure as I dont have 5Ghz on my device. iw event should tell you what events are happening on wifi.
i have the scan command run every 30 sec and I haven't experience any drop out. It's not a fix but a workaround

1 Like

would you be kind to explain why use scan trigger freq 2447 instead of simply scan?
is this due to CPU usage or are there other reasons?

1 Like

one channel scan is quicker than full scan. I have noticed iperf 'beep' and the rate drops on full scan

2 Likes

I found that rc.local will never exit when adding this background process, nohup does not exist with ash.

I'm running background services forked off rc.local like this: Ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beacon - #5 by Catfriend1

Also planning to update this watchdog to act iw event code based just-in-time with the iw scan if this thread and input by @sammo turns out to be a better solution to work around wifi problems on the Archers.

this will put it into background in /etc/rc.local

while sleep 30; do iw dev $(iw dev|grep "Interface\|channel\|type"|grep -B 2 'channel.*24..'|grep -B 1 'AP'|tail -n 2|grep Interface|awk '{print $2}') scan trigger freq 2447 flush >/dev/null 2>&1; done &

@Catfriend1

Have you managed to crash the 2.4GHz wifi with the workaround? I dont have a tp link C7, but a ath9k f/w device

I haven't used the workaround yet as I first wanted to see what iw event shows in case of "wifi crash". Currently wifi is rock solid so still waiting for a normal spontaneous crash scenario to come.

maybe run the loop scan and hammer it with iperf. No point going further if scan does not prevent a crash

@sammo, with the command top, you will see rc.local will never exit because its sub-process 'while sleep 30...' will never exit.

@Catfriend1, I can confirm that when 2.4GHz freeze, iw dev wlan1 scan will revive the clients, I did not know sammo's quicker (less cpu) trick.

1 Like

@zen1932, thanks for the confirmation it works on the C7
you can always set a cron to run every minute for the scan
Periodic scan should prevent it locking. Scanning 1 channel is quicker and blocks the wifi for less time, we are talking millisecond

@zen1932 Great observation! Could you please try

iw event -t -f > /tmp/iwevent.log

and upload a copy that shows how it looks like on your Archer when 2.4ghz WiFi locks up?

The same problem on the newest firmware for now.

#Luci

1 Like

@Catfriend1, I am monitoring the event 84 and 64, otherwise it is rather verbose. but since the 2.4Ghz freeze randomly, I may wait long before getting the results.

@sammo, I had already set a cron job, but a full scan, now thanks to your finding I will replace it with your quicker scan.

1 Like

Shorten a few commands

iw dev $(iw dev|grep "Interface|channel|type"|grep -B 2 'channel.*24..'|grep -m 1 -B 1 'AP'|awk '/Interface/ {print $2}') scan trigger freq 2447 flush >/dev/null 2>&1

2 Likes

Nice, but would it not be less CPU (given this is running every 30 to 60 seconds) to pre-compute the command once and just use the values that work for your deployment?

So like this:

# 5Ghz – ch 161

iw dev wlan1 scan trigger freq 5805 flush 

# 2.4GHz -  ch 8

iw dev wlan0 scan trigger freq 2447 flush

BTW- this works fine on MT7621 / 7603 as well as the C7 (I have both). So this workaround seems to point the finger at something common to several (all?) platforms.

Here is a NetSpot signal scan for the past 30 minutes showing how even in a crowded WiFi environment that causes the OpenWRT APs to lower their 2.4 radio signals, is maintained at a high level with a scan every 60 seconds. Top trace (Brown is the 2.4 radio, next one down (blue) is the 5Ghz radio. AP is 3' from my MacBook Pro running NetSpot.

2 Likes

I think the common problem reported is 2.4Ghz which uses the ath9k driver whereas 5Ghz uses ath10k.

I did 1 channel scan as when I do a full scan I noticed a bleep on my iperf. I think the scan 'blocks' data been sent/received.

Nice graph!!

OK I see what you mean find the wlanXXXXX, yes of course, unless someone did a uci set xxxx
Would be great if someone solves the underlining code than a workaround....

1 Like

Yeah, do NOT do that regularly (at least not on the MT7621) as it drops the link for a second.

Maybe only do it when there is some other clear signal that there is an issue, and this might clear it up.

No drops on the 2.4 GHz radio when running these scans.

[edit: Note that the wlan1 shown here is a 5Ghz on the MT76, on the C7 the 2.4 is wlan1, I keep mixing up which is which (since I run both), but this example and in my prior post were from a test MT76, so use the right wlan ID. The C7 2.4 seems to do well with the probe every 60 seconds.]

it would be great to monitor when the problem happens, You can monitor wifi event via

iw event -f -t > /tmp/event.txt

FYI. None of these workaround works, but could be useful of other purpose/vulnerabilities

disable ipv6
option disassoc_low_ack '0'
option wpa_group_rekey '43200'
option wpa_strict_rekey '1'
option wpa_disable_eapol_key_retries 1
option txantenna 1
option rxantenna 1

1 Like