Archer C7 2.4 GHz wireless dies in 24~48 hours

This is my Archer C7v5 output. Running OpenWrt 21.02.3 here. I did not specify the ldpc option in my /etc/config/wireless config.

grep ht_ca /tmp/run/hostapd-phy*.conf
/tmp/run/hostapd-phy0.conf:ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]
/tmp/run/hostapd-phy0.conf:vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]
/tmp/run/hostapd-phy1.conf:ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]

I think radio1/phy1 is the 2.4 GHz WiFi.

Ran an iperf3 test multiple times, here are the results:

  • 2.4 GHz WiFi without "option ldpc '0'" - ~70 Mbit/sec
  • 2.4 GHz WiFi with "option ldpc '0'" - ~70 Mbit/sec
  • 5 GHz WiFi - ~ 138 MBit/sec

I've made sure to restart the phy radio after adding/removing the option ldpc line. It didn't make any difference. I suspect LDPC is already turned off by OpenWrt 21.02.3's defaults because the "grep ht_ca" above does indicate this.

In my tests, applying the following two patches solves the problem.

https://patchwork.kernel.org/project/linux-wireless/patch/20161117083614.19188-1-sven.eckelmann@open-mesh.com/

https://patchwork.kernel.org/project/linux-wireless/patch/20161117083614.19188-2-sven.eckelmann@open-mesh.com/

To get my 2.4 GHz to work I needed to disable LDPC otherwise it would not properly enable.
Also before the upgrade to 23.05 I got the obnoxious device not found error.

I was facing with the issue described in this post after having upgraded OpenWRT in my Archer C7. I would see my Shelly or Meross devices being offline on a random basis every few days.
After disabling LDPC I can I have not experienced this issue for the past several weeks now. Thank you for posting this solution.

C7 v2 here on 25.12.4. The 2.4 wireless just froze and I had ldpc disabled in advance as an experiment. Had to restart the wireless interface from a LAN machine again.

This ldpc setting by itself is not a fix for whatever this issue is.

I guess the next experiment I will try is unchecking disassociate on low acknowledgement. I already had disable inactivity polling checked. I did look at the log, there are no unusual dhcp or other reporting lines when this issue happens. I will try to look at the iw stats when it happens again.

Purely out of curiousity, when your 2.4ghz radio freezes, could you ssh in from the lan machine and run iw dev phy1-ap0 scan trigger freq 2447 flush? Based on this post above, may recover the radio without a restart.