Wi-Fi stops working after 2 days on Archer C7v2

[ErickEY]

I used to have this problem quite often with my WR842ND, does issuing "wifi" command solves the problem? Probably yes, but only temporary.

Logread didn't show anything relevant other than what you've described. What helped to shed a light, in this case, was gathering data from the following commands when that happened:

Code: Select all

cat /sys/kernel/debug/ieee80211/phy1/ath9k/ani
cat /sys/kernel/debug/ieee80211/phy1/ath9k/reset
cat /sys/kernel/debug/ieee80211/phy1/ath9k/queues

"Stuck Beacon", "Tx DMA stop error", "(BE): pending", would show quite high values when it happened.

Wifi command fixes the issue. Very likely, for another couple of days.
Did you manage to fix the issue or get a workaround (except scheduled reboot)?

As mentioned in the first post, the release from May 25 works fine for 1.5 months. Same devices, same configuration.

[Lantis]

The only difference would be a kernel level change since then. Which i'm not going to be able to fix or diagnose for you.

You probably need to try at Openwrt.

[ErickEY]

The only difference would be a kernel level change since then. Which i'm not going to be able to fix or diagnose for you.

You probably need to try at Openwrt.

The interesting thing is the release of May 25 is the only stable one for my router for some reason. All previous 1.9.x and all the following 1.9.x builds have this problem. Curretly running 1.10.0 and the issue is still there.
That is why I'm looking for a changeset specific to the 1.9.x of May 25.

[d3fz]

Wifi command fixes the issue. Very likely, for another couple of days.
Did you manage to fix the issue or get a workaround (except scheduled reboot)?

I've tried Ping Watchdog as a workaround, that was pointing to a repeater I own as well. Every time the error occurred and repeater stopped responding to pings, PW issued "wifi" command, and everything was back to "normal", at least for a while.

Another alternative I've tried was to disable ANI, which actually helped. Not sure if it will be the case for you, but it's worth a shot.

Add this to /etc/rc.local

Code: Select all

echo 0 > /sys/kernel/debug/ieee80211/phy1/ath9k/ani

Reboot the router afterwards.

Can you please post the output of the commands I mentioned earlier when it happens again?

[ErickEY]

Wifi command fixes the issue. Very likely, for another couple of days.
Did you manage to fix the issue or get a workaround (except scheduled reboot)?

I've tried Ping Watchdog as a workaround, that was pointing to a repeater I own as well. Every time the error occurred and repeater stopped responding to pings, PW issued "wifi" command, and everything was back to "normal", at least for a while.

Another alternative i've tried was to disabled ANI, which actually helped. Not sure if it will be the case for you, but it's worth a shot.

Add this to /etc/rc.local

Code: Select all

echo 0 > /sys/kernel/debug/ieee80211/phy1/ath9k/ani

Reboot the router afterwards.

Can you please post the output of the commands I mentioned earlier when it happens again?

Thanks for a workaround. Will try it. Sure, I will.

[ErickEY]

Disabling ani helped a little: router was stable for about 2.5 weeks. Tonight 2.4 wi-fi died again. Here is the output from the commands:

Code: Select all

            ANI: DISABLED

Code: Select all

(VO):  qnum: 3 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(VI):  qnum: 2 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BE):  qnum: 1 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BK):  qnum: 0 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(CAB): qnum: 8 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0

Code: Select all

    Baseband Hang:  0
Baseband Watchdog: 70
   Fatal HW Error:  0
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang:  3
      PLL RX Hang:  0
         MAC Hang:  0
     Stuck Beacon: 1232
        MCI Reset:  0
Calibration error:  0
Tx DMA stop error:  9
Rx DMA stop error:  0

[d3fz]

Glad to hear that it helped a little bit. A quick "solution" to this problem would be to schedule a reboot every week, I know is not optimal, but a least keeps the system up and running for a longer period of time.

I'm also running latest Gargoyle on a Archer C7 v2, but with ANI enabled (which is now the default) and a weekly scheduled reboot. I've also issued the same commands by the end of the week (just before the reboot), and this is what I got:

Code: Select all

/rom/www$ cat /sys/kernel/debug/ieee80211/phy1/ath9k/ani
            ANI: ENABLED
      ANI RESET: 19
     OFDM LEVEL: 1
      CCK LEVEL: 4
        SPUR UP: 532
      SPUR DOWN: 532
 OFDM WS-DET ON: 0
OFDM WS-DET OFF: 0
     MRC-CCK ON: 21
    MRC-CCK OFF: 31
    FIR-STEP UP: 17299
  FIR-STEP DOWN: 17274
 INV LISTENTIME: 0
    OFDM ERRORS: 108072764
     CCK ERRORS: 197198765

Note: when testing with ANI enabled on the WR842ND, "ANI RESET" numbers would go bonkers when the bug was about to happen.

Code: Select all

/rom/www$ cat /sys/kernel/debug/ieee80211/phy1/ath9k/reset
    Baseband Hang:  0
Baseband Watchdog:  7
   Fatal HW Error:  0
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang:  0
     Stuck Beacon:  8
        MCI Reset:  0
Calibration error:  0
Tx DMA stop error:  0
Rx DMA stop error:  0

Code: Select all

/rom/www$ cat /sys/kernel/debug/ieee80211/phy1/ath9k/queues
(VO):  qnum: 3 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(VI):  qnum: 2 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BE):  qnum: 1 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BK):  qnum: 0 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(CAB): qnum: 8 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0

[ErickEY]

Thank you for the clarification.
That is why I'm wondering if there was something special (related to wireless configuration) done in the build of May 25, 2017. This build was working fine for 1.5 months without any ani tricks.

[Lantis]

The only difference would be a kernel level change since then. Which i'm not going to be able to fix or diagnose for you.

You probably need to try at Openwrt.

Nothing else changed like I said.

[ErickEY]

This time disabling ani did not help. Had to reboot router twice per day. So scheduled reboot is not an option.
Switched back to 1.9.2 build as of May 25. Will wait till merge with LEDE is completed before giving 1.10.x another try.