OpenWrt Forum Archive

Topic: disconnected due to excessive missing ACKs / Failed to stop TX DMA

The content of this topic has been archived on 30 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi, I have one tl-wr841nd in ap mode and client is tl-wr741nd. Today, my remote tl-wr741nd was not able to associate, so I needed do wifi down and wifi on ap wr841nd.

logread from AP wr841nd

Mar 27 08:09:42 wr841nd daemon.info hostapd: wlan0: STA 64:70:02:f8:9f:70 WPA: group key handshake completed (RSN)
Mar 27 08:13:56 wr841nd daemon.info hostapd: wlan0: STA 64:70:02:f8:9f:70 IEEE 802.11: disconnected due to excessive missing ACKs
Mar 27 08:14:26 wr841nd daemon.info hostapd: wlan0: STA 64:70:02:f8:9f:70 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 27 08:14:26 wr841nd kern.info kernel: [1728245.510000] device wlan0.sta1 left promiscuous mode
Mar 27 08:14:26 wr841nd kern.info kernel: [1728245.510000] br-lan: port 4(wlan0.sta1) entered disabled state

After I did wifi up on AP, I was able to telnet to the client wr741nd, because it associated and this is logread from client:

Mar 28 13:27:45 wr741nd kern.err kernel: [1486100.510000] ath: phy0: Failed to stop TX DMA, queues=0x001!
Mar 28 13:27:46 wr741nd kern.info kernel: [1486101.430000] wlan0: authenticate with f8:d1:11:34:a5:c1
Mar 28 13:27:46 wr741nd kern.info kernel: [1486101.460000] wlan0: send auth to f8:d1:11:34:a5:c1 (try 1/3)
Mar 28 13:27:46 wr741nd kern.info kernel: [1486101.670000] wlan0: send auth to f8:d1:11:34:a5:c1 (try 2/3)
Mar 28 13:27:46 wr741nd kern.info kernel: [1486101.880000] wlan0: send auth to f8:d1:11:34:a5:c1 (try 3/3)
Mar 28 13:27:46 wr741nd kern.info kernel: [1486102.090000] wlan0: authentication with f8:d1:11:34:a5:c1 timed out
Mar 28 13:27:46 wr741nd kern.err kernel: [1486102.100000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024e00
Mar 28 13:27:46 wr741nd kern.err kernel: [1486102.110000] ath: phy0: Could not stop RX, we could be confusing the DMA engine when we start RX up
Mar 28 13:27:46 wr741nd kern.err kernel: [1486102.120000] ath: phy0: Failed to stop TX DMA, queues=0x001!
Mar 28 13:27:47 wr741nd kern.info kernel: [1486103.050000] wlan0: authenticate with f8:d1:11:34:a5:c1
Mar 28 13:27:47 wr741nd kern.info kernel: [1486103.080000] wlan0: send auth to f8:d1:11:34:a5:c1 (try 1/3)
Mar 28 13:27:47 wr741nd kern.info kernel: [1486103.080000] wlan0: authenticated
Mar 28 13:27:47 wr741nd kern.info kernel: [1486103.100000] wlan0: associate with f8:d1:11:34:a5:c1 (try 1/3)
Mar 28 13:27:47 wr741nd kern.info kernel: [1486103.110000] wlan0: RX AssocResp from f8:d1:11:34:a5:c1 (capab=0x411 status=0 aid=1)
Mar 28 13:27:47 wr741nd kern.info kernel: [1486103.110000] wlan0: associated
Mar 28 13:27:47 wr741nd kern.info kernel: [1486103.120000] br-lan: port 3(wlan0) entered forwarding state
Mar 28 13:27:47 wr741nd kern.info kernel: [1486103.120000] br-lan: port 3(wlan0) entered forwarding state
Mar 28 13:27:49 wr741nd kern.info kernel: [1486105.120000] br-lan: port 3(wlan0) entered forwarding state

There is still this deaf wifi bug, no matter what BB or AA revision I try, it ends up with the same result one day sad Is there some solution? The only workaround is to periodicaly restart the router, but this is what I don't like and bug can happen after few hours of uptime.

I don't believe what I have found. If **this bug** is related, it is very old, but still not fixed. All tp-link devices I have tested are affected by this bug (wr741nd/wr841nd/wr842nd/wr1043nd). That's bad, because no one knows why this happens and how to fix or at least work around sad

Doesn't look like that completely fixes it

Running recent snapshot

 -----------------------------------------------------
 BARRIER BREAKER (Bleeding Edge, r36859)
 -----------------------------------------------------

According to svn r36859 should contain the ANI_POLLINTERVAL change, but still seeing:

Jun  9 16:38:18 OpenWrt daemon.info hostapd: wlan0: STA 00:24:d7:b1:0e:48 IEEE 802.11: disconnected due to excessive missing ACKs
Jun  9 16:38:48 OpenWrt daemon.info hostapd: wlan0: STA 00:24:d7:b1:0e:48 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Client just sees wifi drop out and not come back. Seems to happen most under load (either iperf or just large downloads).

Found an interesting setting in /var/run/hostapd-phy0.conf - disassoc_low_ack, that seems to impact the low ACK behaviour
http://hostap.epitest.fi/gitweb/gitweb. … 50d22c2887

changed to:

.....
.....
interface=wlan0
ctrl_interface=/var/run/hostapd-phy0
disassoc_low_ack=0
preamble=1
.....
.....

Now does not give me the excessive/missing ACK - however now can trigger this error pretty easilly:

Jun 11 00:38:28 OpenWrt kern.err kernel: [111031.220000] ath: phy0: Failed to stop TX DMA, queues=0x004!

Note that the disassoc_low_ack can be set (at least in BB snapshots) by setting disassoc_low_ack in /etc/config/wireless, e.g.

config wifi-iface
    option device   radio1
    option network  lan
    option mode     ap
    option ssid     OpenWrt
    option encryption psk2
    option key       thisisnotagoodpassword
    option disassoc_low_ack 0

Thank you for investigating this. Have you found some solution?

Adding the 'option disassoc_low_ack 0' to the wireless config seems to make things significantly better.  Been running (a recent snapshot) with this option for the last week. Previously AP was unusable (constantly dropping connections) but has been stable for a week with no 'missing ACK' or 'Failed to stop TX DMA' messages.

Thank you very much, I will try the option.

The deaf-mute wifi bug:

Jun 28 06:33:50 WR741ND daemon.info hostapd: wlan0: STA 20:68:9d:xx:xx:xx WPA: group key handshake completed (RSN)
Jun 28 06:42:41 WR741ND daemon.info hostapd: wlan0: STA 00:1e:65:xx:xx:xx IEEE 802.11: disassociated due to inactivity
Jun 28 06:42:42 WR741ND daemon.info hostapd: wlan0: STA 00:1e:65:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Jun 28 06:42:43 WR741ND daemon.info hostapd: wlan0: STA 20:68:9d:xx:xx:xx IEEE 802.11: disassociated due to inactivity
Jun 28 06:42:44 WR741ND daemon.info hostapd: wlan0: STA 20:68:9d:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

All stations just disassociate for unknown reason. Interface probably stops working, so openwrt thinks thay are inactive. Wifi is not visible anymore. After wifi command everything works again. This really sucks sad

Please try latest trunk (without changes to disassoc_low_ack)

Thank you, is the fix distributed also to AA? BB trunk will make a nice brick of my wr1043nd device, so I can compile only latest AA. But BB works fine on wr841nd and wr741nd, so I can try at least there.

On almost latest trunk (r37620) with TL-MR3420 V2. With disassoc_low_ack set to 0, the wifi is usable with 5% packet loss. Without disassoc_low_ack, the wifi is just unusable with disconnection every few minutes. Testing done with just 1 wireless client.

"option disassoc_low_ack 0" is working brilliantly for me - I've had the wireless running for a few hours without trouble.  I was lucky to get half an hour before.

BARRIER BREAKER (Bleeding Edge, r38461)
Bus 001 Device 002: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]

retride wrote:

"option disassoc_low_ack 0" is working brilliantly for me - I've had the wireless running for a few hours without trouble.  I was lucky to get half an hour before.

BARRIER BREAKER (Bleeding Edge, r38461)
Bus 001 Device 002: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]


Is  disassoc_low_ack available por AA 12.09 ?

Hi
Same issue and same solution (option disassoc_low_ack 0) I have experienced here with my TP-Link WR841N (8.4).
The very strange thing is that I have two of these routers, both bought from Amazon, very close in serial number, loaded with same AA, same config (only AP channel is different), and only one of the router show the problem, having the same clients connected!
Unfortunately, I cannot be sure which, but one of this modem got loaded with dd-wrt, then I've put back stock firmware and went to openwrt. I cannot see how it can have anything to do with the issue, but that're the facts! Fortunately the solution is available
Bye

Hi, one more info. With the suggested option, the problem is mitigated but not solved. Every two days I have to reboot the router otherwise I get WiFi instability. What logs can I check to try to identify the problem?

Wed Jan 29 16:47:49 2014 daemon.info hostapd: wlan0: STA e0:b9:a5:f5:d9:a0 IEEE 802.11: disconnected due to excessive missing ACKs
Wed Jan 29 16:47:58 2014 daemon.info hostapd: wlan0: STA e0:b9:a5:f5:d9:a0 IEEE 802.11: authenticated
Wed Jan 29 16:47:58 2014 daemon.info hostapd: wlan0: STA e0:b9:a5:f5:d9:a0 IEEE 802.11: associated (aid 1)

I have the dir-620/d1, just set the option disassoc_low_ack 0 ?

Same happens here. Makes WiFi unusable. It's very unstable.

Wed Jan 29 12:51:08 2014 daemon.info hostapd: wlan0: STA 00:16:dc:6e:e5:73 IEEE 802.11: disconnected due to excessive missing ACKs
Wed Jan 29 12:51:38 2014 daemon.info hostapd: wlan0: STA 00:16:dc:6e:e5:73 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

OpenWrt Barrier Breaker r39382

TTLucian wrote:

Same happens here. Makes WiFi unusable. It's very unstable.

Wed Jan 29 12:51:08 2014 daemon.info hostapd: wlan0: STA 00:16:dc:6e:e5:73 IEEE 802.11: disconnected due to excessive missing ACKs
Wed Jan 29 12:51:38 2014 daemon.info hostapd: wlan0: STA 00:16:dc:6e:e5:73 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

OpenWrt Barrier Breaker r39382

Powered by LuCI Trunk (svn-r9951) OpenWrt Barrier Breaker r39406

I'm having the exact same problem on my TP-Link Archer C7. Chaos Calmer RC2. Deauthenticated and missing ACKs.

(Last edited by adrian.au.gm on 21 Jun 2015, 05:49)

exactly same problem here, CC RC2 on Archer C7v2, only on 5ghz (ath10k)

Just trying to do a little debugging:

adrian.au.gm: Are you using SQM QoS? (I am!)

SQM should have no impact on this

drawz wrote:

SQM should have no impact on this

You are right drawz, I suspected of SQM because of the drops in dequeue mechanism, maybe interfering with loss of ACK's detection. But with SQM disabled, drops still exists.

The discussion might have continued from here.