unstable wireless connection on WZR-HP-G300NH ar71xx

[Anton <anton.bugs@…>]

Hi, I've flashed my buffalo g300 with Backfire RC4 (openwrt-ar71xx-wzr-hp-g300nh-jffs2-sysupgrade.bin). Sadly, the wireless connection is still unstable and keep disconnecting randomly. I didn't experience this problem with the original firmware.

I've restricted wireless to 11g via wireless.radio0.hwmode (as wiki suggested) but it didn't help.

The system log file attached to this ticket, please let me know if I can provide anything else useful for debugging and fixing the problem.

[Gorby]

I recommend to flash to latest trunk. The problem is well (i hope!) known and there were some tickets about. The instability with ath9k drivers is slowly fixing during the further development. Stay tuned.

[jow]

The mac indicates that the client uses an intel radio. Which chipset exactly? Did you try to update the drivers on the client?

[Anton <anton.bugs@…>]

It's not about client. I have 3 wifi devices, all of them effected.

Just in case, it's PRO/Wireless 2200BG [Calexico2], net-wireless/ipw2200-firmware-3.1 with sys-kernel/gentoo-sources-2.6.36. The second client is wip300 linux-based sip phone.

Again, it was working fine with the original firmware and I haven't tried dd-wrt.

ps. How can I subscribe to a bug report so I would receive a mail with each update?

[nbd]

Normally adding your email address to Cc should be enough to receive an update.
About your issue: please try latest trunk. There were some updates recently that should help with various compatibility issues.

[Anton <anton.bugs@…>]

the trunk from 11 Dec is still affected

[Anton <anton.bugs@…>]

Some more weird logs

[Anton <anton.bugs@…>]

I've found that dd-wrt might have a similar bug:
​http://www.dd-wrt.com/wiki/index.php/Buffalo_WZR-HP-G300NH#Fix_for_wifi_Dropouts

How about downloading the buffalo's source code and compare it with openwrt?
​http://opensource.buffalo.jp/gpl_wireless.html
​http://buffalo.jp/php/los.php?to=gpl/wireless/gpl_wzr-hp-g300nh_160.tar.gz

[Jeff Beard-Shouse <clarke.hackworth@…>]

I am having the same issue, my logs look almost identical to the ones provided in this bug. I have the WZR-HP-G300NH router and am running Backfire 10.03.1-rc4. If it is needed I may be able to test with trunk over the holiday.

[nbd]

Yes, please try that.

[clarke.hackworth@…]

Replying to nbd:

Yes, please try that.

Ok

To be clear as to the problems I do get random wifi disconnects, however the actual disconnections happen about every 1-2 days. This is not that big of deal to me as the operating systems I run just reconnect. I do receive the "WPA: group key handshake completed (RSN)" log messages about every 10-20 minutes.
However what is a bigger deal to me is the wifi stops working about every 1/2 day to 2 days. By stops working I mean all clients get kicked off and the ssid no longer shows up when I scan from a client. The router then needs to be rebooted or the networking subsystem restarted. I am unsure whether this behavior is related to this bug.

I have tried using truck as of Thursday of last week. I have also tried using trunk with kernel 2.6.37. Both have had the same issues (actually my impression was the newer kernel seemed to have the wifi stop more). It may be a coincidence but it seems like the wifi stopping happens more often when I am using a cisco vpn, and/or a bittorrent client, than with regular web traffic (including streaming video). Not sure why that would be, or since I dont have any hard numbers and or facts about it, if it just seemed that way to me.

With the trunk builds I am also seeing new error messages in the log:
kernel: ath: Failed to stop TX DMA in 100 msec after killing last frame
kernel: ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
and
kernel: ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020

[nbd]

The error message is not new, it was just hidden before.
Stability should be much better as of r24962 (backfire), r24954 (trunk)
Please test again.

[clarke.hackworth@…]

Replying to nbd:

The error message is not new, it was just hidden before.
Stability should be much better as of r24962 (backfire), r24954 (trunk)
Please test again.

I have been running trunk r24961, since yesterday. I have had the wireless network stop once so far.

[clarke.hackworth@…]

Just an update I have trunk r24966 and kernel 2.6.37. The wireless clients drop connections about 3-4 times a day along with the occasional wifi network drop out (1-2 a day).

I did notice that when the wifi network drops out. I get about a log message a second relating to "kernel: ath: Failed to stop (TX/RX)"

[anonymous]

Has this been fixed yet?

[clarke.hackworth@…]

I have been running r25472 for about a day and a half. I have not any connection issues like I have had with other builds. It means that this issue may be fixed, however I will need to run for a few more days without problems to be completely sure. I will report back then.

[clarke.hackworth@…]

I have been running r25472 for 2 full days now and it just had connection problems again. I get log messages like:

Feb 14 10:00:00 OpenWrt user.err kernel: ath: Failed to stop TX DMA in 100 msec
after killing last frame
Feb 14 10:00:00 OpenWrt user.err kernel: ath: Failed to stop TX DMA in 100 msec
after killing last frame
Feb 14 10:00:00 OpenWrt user.err kernel: ath: Failed to stop TX DMA!
Feb 14 10:00:00 OpenWrt user.err kernel: ath: DMA failed to stop in 10 ms AR_CR=
0x00000024 AR_DIAG_SW=0x42000020
Feb 14 10:00:00 OpenWrt user.err kernel: ath: Could not stop RX, we could be con
fusing the DMA engine when we start RX up

every second and the wifi network is not operational (it does not show up as a network when clients scan). The problem corrected itself in about 20 minutes, but then started up again after 5-10 minutes. A reboot temporarily solves the problem.

I would say this bug is not fixed. :-(

[anonymous]

Just wanted to point out that I am experiencing this same issue with both OpenWRT and the latest version of DD-WRT (rev. 16144) on this router. It is a commonly reported issue with DD-WRT, though stock firmware does not seem to exhibit the same problem.

[anonymous]

Replying to anonymous:

Yes, it is already been highlighted in the comment #6 that the source code of the stock firmware is public. All we have to do now is to compare two different sources (which is I guess not an easy job) and come up with a proper patch which would fix *that* problem. Sorry, but I don't like "please try the latest trac version" approach. It didn't work for the last 6 month.

[jow]

All we have to do now is to compare two different sources (which is I guess not an easy job) and come up with a proper patch which would fix *that* problem.

I wonder how you intend to compare a binary driver blob to the ath9k sources.

[anonymous]

Not to mention that the stock firmware does appear to exhibit similar behavior, albeit not as often as Buffalo's DD-WRT version.

[nbd]

Please try latest trunk or backfire, stability should be better now.

[clarke.hackworth@…]

I am now running r26018. It still seems to be happening. Clients get disconnected and "Failed to stop TX" messages every second in the log. The behavior stops after a while. In my latest case I think it happened for 5 minutes or so, but I have seem it last up to 20 minutes in the past.

I am a programmer and know some C/C++. However I am not as familiar with coding for openwrt. If someone out there who is working on this wants help, I would be willing to try my hand at working on it. All I would need is to be brought up to speed on what current theories are on this bug, and where/how to get started working on it. Send me an email: clarke.hackworth@…

[clarke.hackworth@…]

grr, it always seems to obscure email addresses. contact me here: clarke.hackworth (at) gmail.com

[nbd]

were you using HT20 or HT40?

[nbd]

Committed some more fixes in r26167, r26172
Please test.

[frankbernier@…]

Hi, I got this router last week and got the same issue on DD-WRT. I tried the very latest build I could and got the same results, so I decided to give OpenWRT a try. Setup was a breeze with opkg making everything very easy (got a working NTFS NAS, PPTP, and everything else setup very easily). I found the snapshots and installed the one from march 16th. So far so good with a 24 hour uptime on HT40 (was using "auto" on DD-WRT but I think it was using HT20). I'm still configuring lots of stuff so I may end up rebooting but I'll report if it fails again or after like a week of uptime. Thank you for your work!

[Anton <anton.bugs@…>]

see more details in the log

[Anton <anton.bugs@…>]

nbd,

I really appreciate your work, however need to report that it is still not fixed for me. The connection still drops quite often. See the log file for details.
Also, I've got a personal feeling that the official dd-wrt is more stable then the current trunk.

Thanks.

[nbd]

Anton: Did you have issues with DD-WRT as well, or did everything work there with the same client - have you made a direct comparison?
Also, which version of iwlagn/mac80211 are you using on the client?

[Anton <anton.bugs@…>]

both client and openwrt logs

[Anton <anton.bugs@…>]

I've done more testing with 4 different clients. Here is the results:

iwlang
02:00.0 Network controller: Intel Corporation Device 4239 (rev 35)
sys-kernel/gentoo-sources-2.6.38
net-wireless/iwl6000-ucode-9.221.4.1
dd-wrt: works fine
openwrt: works ok with some errors as in the attachment

ipw2200
02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)
net-wireless/ipw2200-firmware-3.1
sys-kernel/gentoo-sources-2.6.36-r5
dd-wrt: works fine
openwrt: works ok with some errors as in the attachment

samsung n150
05:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
ubuntu 10.10 up to date
dd-wrt: works fine
openwrt: connection drops after sometime and never goes back

linksys wip300
00:14:bf:fe:6a:7c
dd-wrt: connection drops after sometime but gets back after that
openwrt: connection drops after sometime but gets back after that
used to work fine with the original firmware

[nbd]

Anton: Are you using Legacy, HT20 or HT40? Does using legacy 11g mode prevent connection drops with the current version?

Thanks

[nbd]

Another thing: Please make sure ath9k is compiled with CONFIG_PACKAGE_ATH_DEBUG=y
set in the OpenWrt .config.
After booting your router, run this:

rmmod ath9k
insmod ath9k debug=0x8001

This will show messages in the log when the wireless hardware gets reset due to baseband hang issues or stuck beacons.

[Anton <anton.bugs@…>]

nbd,

I've downloaded the firmware from
​http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-wzr-hp-g300nh-jffs2-sysupgrade.bin
wifi settings are almost default, I've just enabled WPA2 PSK encryption. So it was HT20 with 11g+n.

I've reloaded driver with debug option and switch it to 11g. samsung n150 client is stable now, the rest seems the same.

The log file is still not detailed though. Could you compile it with debug config for me please?

ps. I've found a similar bug report in the ticket ​/ticket/8330.html

[anonymous]

Openwrt: Backfire (10.03, r26231)
Device: Tp-Link TL-WR1043ND v1.8
Client: Windows 7 64 bit, RTL8187B, drivers version: 62.1181.1105.2009

wifi connection drops after few hours...

# dmesg
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020

# cat /etc/config/wireless
config 'wifi-device' 'radio0'
        option 'type' 'mac80211'
        option 'macaddr' '74:ea:xx:xx:xx:xx'
        option 'disabled' '0'
        option 'channel' '1'
        option 'hwmode' '11g'
        option 'country' 'PL'

config 'wifi-iface'
        option 'device' 'radio0'
        option 'network' 'lan'
        option 'mode' 'ap'
        option 'ssid' 'xxxxx'
        option 'encryption' 'psk2'
        option 'key' 'xxxxxxxxxxxxx'

[jeyjay]

same here with recent trunk (r26232)
Device: Asus WL-500gP with Atheros miniPCI (ath9k)

Mar 20 23:45:40 Internetgemeinschaft daemon.notice hostapd: wlan0: STA 00:1d:fe:xx:xx:xx IEEE 802.11: did not acknowledge authentication response
Mar 20 23:45:46 Internetgemeinschaft daemon.notice hostapd: wlan0: STA 00:1d:fe::xx:xx:xx IEEE 802.11: did not acknowledge authentication response
Mar 20 23:45:49 Internetgemeinschaft daemon.notice hostapd: wlan0: STA 00:1d:fe::xx:xx:xxe IEEE 802.11: did not acknowledge authentication response
Mar 20 23:50:41 Internetgemeinschaft daemon.info hostapd: wlan0: STA 00:1d:fe::xx:xx:xx IEEE 802.11: disassociated due to inactivity
Mar 20 23:50:42 Internetgemeinschaft daemon.info hostapd: wlan0: STA 00:1d:fe::xx:xx:xx IEEE 802.11: deauthenticated due to inactivity
Mar 20 23:51:12 Internetgemeinschaft daemon.notice hostapd: wlan0: STA 00:1d:fe::xx:xx:xx IEEE 802.11: did not acknowledge authentication response

ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020

[nbd]

Please test with r26252 - the bogus inactivity timeouts should be gone now.

[anonymous]

Replying to nbd:

Please test with r26252 - the bogus inactivity timeouts should be gone now.

Latest snapshot is r2652. When you ask to test you want us to compile it ourself, or is it hosted elsewhere?

[anonymous]

Replying to anonymous:

Replying to nbd:

Please test with r26252 - the bogus inactivity timeouts should be gone now.

Latest snapshot is r2652. When you ask to test you want us to compile it ourself, or is it hosted elsewhere?

My bad... r26232

[Anton <anton.bugs@…>]

we just need to wait for it to get compiled in couple more hours. It should be at 21 Mar 8am of some time zone ;-) I can't wait too.

[tuigje]

Hi,

some bad news, I'm afraid. With the following source:

Path: .
URL: svn://svn.openwrt.org/openwrt/branches/backfire
Repository Root: svn://svn.openwrt.org/openwrt
Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73
Revision: 26267

I still get:

ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020

[nbd]

As mentioned in another ticket:

The message is a known issue and is not necessarily an indicator of a connection hang. Please only reopen the ticket if you have something that is relevant to this issue.

[jeyjay]

I reopened #8446 for dying wireless with ath9k 11n.

[Anton <anton.bugs@…>]

Thanks jeyjay. I have recompiled the trunk with the debug option and will try to provide more info there.
Meanwhile, I have opened a separate ticket #9122 for dying wifi on a wip300 sip phone.

[richard-laing@…]

Hi has this problem been fixed as I have OpenWrt Backfire 10.03.1-RC6 installed however I am still getting WIFI drops

[anonymous]

Hi,

I also have this problem. Wifi is dropped randomly specially when we download large file from local (use max bandwidth of wifi connection I think.)