Modify

Opened 8 years ago

Closed 7 years ago

Last modified 4 years ago

#6667 closed defect (fixed)

hostapd stops working out of a sudden

Reported by: anonymous Owned by: nbd
Priority: high Milestone: Barrier Breaker 14.07
Component: packages Version: Kamikaze trunk
Keywords: hostapd Cc:

Description

I'm using kamikaze trunk r19235 with kmod-ath9k - 2.6.31.12+2010-01-15-1 and after a few hours, all client connections either get dropouts or it's not working at all. The log tells different things, like

Feb 9 20:23:57 tigon daemon.info hostapd: wlan0: STA 00:1e:c2:bc:39:60 IEEE 802.11: deauthenticated due to inactivity

or

Feb 9 20:23:58 tigon daemon.info hostapd: wlan0: STA 00:23:12:c6:f4:3e WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter

It often helps to just type wifi on the console, though every now and then the clients responding with timeouts while authenticating.

This problem is persistent for months with various revisions.

Attachments (4)

warning_trace.txt (1.3 KB) - added by solca 8 years ago.
Probably related.
log.txt (27.1 KB) - added by marc 8 years ago.
ath debug output
ath9kdebug=0xffffffff_1.log (702.2 KB) - added by Alex 8 years ago.
initiated file transfer causes connection "loss" (timeouts instead of 8ms ping time)
ath9kdebug=0xffffffff_2.log (588.4 KB) - added by Alex 8 years ago.
initiated file transfer causes connection "loss" (timeouts instead of 8ms ping time)

Download all attachments as: .zip

Change History (69)

comment:1 Changed 8 years ago by jeyjay

Same here. Using r19536 with Kernel 2.6.32. Hardware: ASUS WL-500gP with ath9k MiniPCI modification. There is no authentication possible after a few hours or days of uptime.
Connection drops silently. There is no automatic attempt of reconnection. Manual reconnect is not possible because of authentication problem.

Perhaps this problem is connected to changeset r19474 and r19476 which solved rekeying problem (disconnects every few minutes) for me.

comment:2 Changed 8 years ago by solca

Same problem here on Linksys WRT160NL.

Reinit with (wifi up) or (rmmod/insmod ath9k{,common,hw} and wifi up) fix the problem.

Changed 8 years ago by solca

Probably related.

comment:3 Changed 8 years ago by kauczu

Got the same identical problem described by jeyjay. Using hardware: ASUS WL-500gP with ath9k MiniPCI (TL-WN861N).

comment:4 follow-up: Changed 8 years ago by solca

It seems disabling 802.11N mode with 'hwmode 11g' in /etc/config/wireless bypasses the problem. Will have to wait more to be sure.

Anybody can confirm this too?

comment:5 in reply to: ↑ 4 Changed 8 years ago by nague

I confirm: no issue after disabling 802.11N mode with 'hwmode 11g' in /etc/config/wireless.

comment:6 Changed 8 years ago by Rajan

(I was the creator of this issue)

I found that out as well, in the meantime. That's really a shame, since I replaced my ath5k card with that ath9k card in order to get draft-n and be able to actually use my 50 MBit-DSL...

I hope it's gonna be fixed soon.

comment:7 Changed 8 years ago by jeyjay

r19759 (wireless-testing 2010-02-16) still has disconnect problem.

comment:8 Changed 8 years ago by jeyjay

ACK. Disabling 11n helps to keep connection up and stable. Infrequent disconnects are also gone.

comment:9 Changed 8 years ago by nbd

  • Owner changed from developers to nbd
  • Status changed from new to accepted

comment:10 Changed 8 years ago by Comprodtv

Had same problems with TL-WN951N. (Ubunto 9.10, 2.6.31-20-generic, with driver ath9k). Internet Connection drops after a few minutes (although AP IP is set). Can reconnect using Network Manager (that re-establish connection, but only for a few minutes)
Seems the card it is Supported on 9.10 . But ¨Don't know whether IEEE 802.11n works¨
https://help.ubuntu.com/community/HardwareSupportComponentsWirelessNetworkCardsTP-Link

Have Set AP to broadcast G+N. Connection drops silently. There is no automatic attempt for reconnection. Manual reconnect is possible via Disconnect / Connect in Network Manager.

Have Set AP to broadcast G only. It now works using NetworkManager = no drop-outs

Have Removed NetworkManager and installed Wicd.

Have Set AP to broadcast G only. It now works using Wicd = no drop-outs.

Have Set AP to broadcast G+N. Connection drops silently. There is no automatic attempt for reconnection. Manual reconnect is possible via Disconnect / Connect in Wicd.

Also iwconfig shows Bit Rate=0 kb/s and sometimes Bit Rate=1 Mb/s although connected. Surely this should show 54Mb/s (for G) and 300Mb/s (for N)

comment:11 Changed 8 years ago by nbd

  • Resolution set to fixed
  • Status changed from accepted to closed

should be fixed in r20499

comment:12 Changed 8 years ago by jeyjay

  • Resolution fixed deleted
  • Status changed from closed to reopened

...the problem still persists in r21033. First I got disconnects and after some time reconnect was not possible. Only-g-mode seems to be working well.

Asus 500-gP with Atheros miniPCI (TP-Link TL-WN861N)

comment:13 Changed 8 years ago by anders_gud <anders.gudmundsson@…>

Same problem here on a TL-WR1048ND... Disabling "n" mode fixed dropouts and unstable wifi. (two TL-WR1048ND on stock 10.03 with wds).
Still got the "received EAPOL-Key 2/4 Pairwise with unexpected replay counter" messages though.

comment:14 Changed 8 years ago by anonymous

on r21295 same problem. Router is TL-WR1048ND. Still looking for more information about the problem, but one thing is sure. If N client is connected and then G client connects, after a while both clients get dropped out. If only N client uses everything is fine. If only G client uses it is fine(kind of).

comment:15 Changed 8 years ago by nbd

please try r21578 or later

comment:16 Changed 8 years ago by isomorphix

I have been experiencing this same problem with my brand new Buffalo WZR-HP-G300NH.

I've tried both the 10.03 release and am currently running r21681, kmod-ath9k 2.6.32.14+2010-05-24-1, and hostapd 20100418-1.

/etc/config/wireless:

config 'wifi-device' 'radio0'
        option 'type' 'mac80211'
        option 'macaddr' '***'
        option 'hwmode' '11ng'
        list 'ht_capab' 'SHORT-GI-40'
        list 'ht_capab' 'DSSS_CCK-40'
        option 'channel' '1'
        option 'htmode' 'HT40+'
        option 'disabled' '0'

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

Let me know if there is any other information I could provide that would help.

comment:17 Changed 8 years ago by hillyunews@…

Same problem encountered, I am using buffalo G300NH, with backfire-stable, I am experience this problem only when windows client connected, if pure mac clients, there will be no such a problem at all, hope this helped. waiting for good news.

comment:18 follow-up: Changed 8 years ago by Matt Turner

I updated to r21838 four days ago, and I have not experienced one instance of the router's wireless dieing.

In the previous four days until I updated, it must have died four or five times. The symptoms were: all wireless connections die, dmesg reports that direct probes to the router time out. The router, and wired connections, still work properly. Rebooting the router is the only way to regain wireless connections.

comment:19 Changed 8 years ago by isomorphix

Unlike hillyunews, I was experiencing the problem with my Macbook Pro. I am going try the latest snapshot today and see how that goes.

comment:20 Changed 8 years ago by isomorphix

This is still happening in r21897, however it seems as though it may have improved slightly. It will work for anywhere from 30 minutes to a few hours after a reboot. Wifi will disconnect for about a minute, then come back on. From this point on, the disconnects happen very frequently, perhaps every 5 minute or so.

In the past, it took a reboot to regain any wifi connection whatsoever. However, wifi dropping out that frequently is still fairly unusable, so a reboot is ultimately required.

comment:21 Changed 8 years ago by gspiliot

I can confirm that is still happening in r21899. Somehow I think it is related to the saturation of the wireless channel. I can get the symptom happening frequently if I choose channel 6 (which is the most commonly used in the neighborhood) whereas it can become quite less frequent when I use the overly less saturated channel 1. Using HT40 surely makes things even worse. 11g is rock stable.

comment:22 Changed 8 years ago by nbd

Added some more fixes, which have fixed disconnection issues for a few people.
Please try trunk r22048

comment:23 Changed 8 years ago by anonymous

HT40 also significantly increases the occurrence of the disconnects for me. I also notice it happens more quickly and more often if I am transferring large files or downloading something. When the laptop is just sitting idle, it happens much less often.

I will be trying out a new build today and will report back once I've tested it for a while.

comment:24 in reply to: ↑ 18 Changed 8 years ago by Matt Turner <mattst88@…>

Replying to Matt Turner:

I updated to r21838 four days ago, and I have not experienced one instance of the router's wireless dieing.

In the previous four days until I updated, it must have died four or five times. The symptoms were: all wireless connections die, dmesg reports that direct probes to the router time out. The router, and wired connections, still work properly. Rebooting the router is the only way to regain wireless connections.

Disregard what I said here. The changes helped, but didn't fix the problem.

I've since upgraded to r22061, but it _still_ disconnects. I love tinkering with computers, but I just want my router to work.

When it disconnects, I see this in dmesg on connected computers.

cfg80211: Calling CRDA to update world regulatory domain
wlan0: authenticate with 00:1d:73:b4:8d:11 (try 1)
wlan0: authenticated
wlan0: associate with 00:1d:73:b4:8d:11 (try 1)
wlan0: RX AssocResp from 00:1d:73:b4:8d:11 (capab=0x11 status=0 aid=1)
wlan0: associated
wlan0: deauthenticated from 00:1d:73:b4:8d:11 (Reason: 2)
cfg80211: Calling CRDA to update world regulatory domain
wlan0: authenticate with 00:1d:73:b4:8d:11 (try 1)
wlan0: authenticated
wlan0: associate with 00:1d:73:b4:8d:11 (try 1)
wlan0: RX AssocResp from 00:1d:73:b4:8d:11 (capab=0x11 status=0 aid=1)
wlan0: associated
wlan0: deauthenticated from 00:1d:73:b4:8d:11 (Reason: 2)
cfg80211: Calling CRDA to update world regulatory domain
wlan0: authenticate with 00:1d:73:b4:8d:11 (try 1)
wlan0: authenticated

I can't continue resetting the router twice a day. I'm flashing the original firmware in the hopes that it's stable.

comment:25 follow-ups: Changed 8 years ago by nbd

I suggest updating to r22088, it contains a fix for another critical issue that matches some of the described symptoms.
When your disconnects happen, are they recoverable through running 'wifi' on the router, or does only a reboot fix them?

comment:26 in reply to: ↑ 25 Changed 8 years ago by Matt Turner <mattst88@…>

Replying to nbd:

I suggest updating to r22088, it contains a fix for another critical issue that matches some of the described symptoms.
When your disconnects happen, are they recoverable through running 'wifi' on the router, or does only a reboot fix them?

Yes, I can run wifi down and then wifi up and it works.

Waiting for a r22088 image snapshot. I downloaded the new one uploaded yesterday (Jul 9) but it was still build r22061...

comment:27 Changed 8 years ago by anonymous

Hi, I used the last snapshot from trunk to build my own image! I still have these disconnection problems. After a while o usage the wifi gets disconnected, sometimes it automatically connects back sometimes you have to to it manually. The worst case is when even manually reconnection is not working. Then I have to connect to the router via cable and restart it, afterwards it works again (for a while). When the worst case takes place the network is detectable by my notebooks wifi software but only with very poor signal strength.

my laptop is a macbook and I am connected with N-speed.

So what is this problem causing? It persists and persists for a couple of month now and it looks like nobody has any clue what it is caused by?!
It is really annoying to have these problems, I think this should be one of the mayor things that should be fixed as soon as possible!

Thorsten

comment:28 Changed 8 years ago by gspiliot

Despite the fact that the previous poster had disconnects I am using r22137 for 4 days now and it seems to be very stable without any problems (disconnections or otherwise) so far.

The problems described by the previous poster were the exact ones I had before my last try of r22137. I haven't changed my environment (i.e., still have the same computers connecting to the AP, and the same, sometimes, heavy traffic) so I can safely say (fingers crossed!) that this is the most stable release I have used so far. I will test for another week and I will report again. Lets hope that latest releases haven't broke anything.

comment:29 Changed 8 years ago by gspiliot

I have spoken too early... While it seems more stable for "n" clients (no disconnects) and the logs are quiet at the beginning, there are still issues with the "g" clients. After 3 days the logs started to be very busy:

Jul 16 10:42:54 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:42:54 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: associated (aid 3)
Jul 16 10:42:55 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e WPA: pairwise key handshake completed (RSN)
Jul 16 10:42:56 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:01 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: disassociated
Jul 16 10:43:01 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:43:01 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: associated (aid 3)
Jul 16 10:43:01 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:04 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: disassociated
Jul 16 10:43:05 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: deauthenticated due to inactivity
Jul 16 10:43:06 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: authenticated
Jul 16 10:43:06 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: associated (aid 1)
Jul 16 10:43:06 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:07 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: disassociated
Jul 16 10:43:07 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:43:07 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: associated (aid 3)
Jul 16 10:43:07 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:10 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: disassociated
Jul 16 10:43:11 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: deauthenticated due to inactivity
Jul 16 10:43:13 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: authenticated
Jul 16 10:43:13 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: associated (aid 1)
Jul 16 10:43:13 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: disassociated
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: Station tried to associate before authentication (aid=-1 flags=0x0)
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: authenticated
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: associated (aid 1)
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:18 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:43:18 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: associated (aid 3)
Jul 16 10:43:18 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e WPA: pairwise key handshake completed (RSN)

... and after a while both "g" clients were "thinking" that were disconnected (despite the fact that they were retrying all the time). Hostapd also consumes more cpu time. So this is surely an indication of a memory leak or a degradation of the service over time... A reboot fixed the issue for the moment.

Lets hope a later revision will patch ath9k or hostapd.

George.

comment:30 Changed 8 years ago by gspiliot

Bad way to include a log. The correct one is:

Jul 16 10:42:54 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:42:54 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: associated (aid 3)
Jul 16 10:42:55 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e WPA: pairwise key handshake completed (RSN)
Jul 16 10:42:56 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:01 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: disassociated
Jul 16 10:43:01 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:43:01 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: associated (aid 3)
Jul 16 10:43:01 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:04 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: disassociated
Jul 16 10:43:05 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: deauthenticated due to inactivity
Jul 16 10:43:06 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: authenticated
Jul 16 10:43:06 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: associated (aid 1)
Jul 16 10:43:06 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:07 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: disassociated
Jul 16 10:43:07 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:43:07 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: associated (aid 3)
Jul 16 10:43:07 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:10 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: disassociated
Jul 16 10:43:11 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: deauthenticated due to inactivity
Jul 16 10:43:13 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: authenticated
Jul 16 10:43:13 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: associated (aid 1)
Jul 16 10:43:13 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: disassociated
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: Station tried to associate before authentication (aid=-1 flags=0x0)
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: authenticated
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed IEEE 802.11: associated (aid 1)
Jul 16 10:43:16 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:b0:ed WPA: pairwise key handshake completed (RSN)
Jul 16 10:43:18 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: authenticated
Jul 16 10:43:18 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e IEEE 802.11: associated (aid 3)
Jul 16 10:43:18 192.168.10.1 hostapd: wlan0: STA 00:XX:XX:XX:17:3e WPA: pairwise key handshake completed (RSN)

comment:31 in reply to: ↑ 25 Changed 8 years ago by Alex

Hi!

After r22048 the situation definitely got better!
So now I will upgrade to something beyond r22152 (so with the additional r22088 and the some more fixes there I hope it will get real reliable finally).

But what I really want to know: How did you debug the leak?
For such a long time I've replicated my/the failure for several times, but I just wasn't able to find the bug.. . So what would have helped me to find it. I've had the failure regularly, and watched the mac80211 changes since months now because of that.

Thank you!

Alex

Replying to nbd:

I suggest updating to r22088, it contains a fix for another critical issue that matches some of the described symptoms.
When your disconnects happen, are they recoverable through running 'wifi' on the router, or does only a reboot fix them?

comment:32 follow-up: Changed 8 years ago by nbd

I found almost all of the issues through code review

comment:33 in reply to: ↑ 32 Changed 8 years ago by Alex

Okay, so I'm not good enough with the code ;-).
So you're commiting to wireless testing, which then results in a new compat-wireless-2.6 after some time, which you then use for openwrt so that after that you can remove the patchfiles which are used here currently?

Replying to nbd:

I found almost all of the issues through code review

comment:34 follow-up: Changed 8 years ago by anonymous

Just curious, does enabling CONFIG_PACKAGE_ATH9K_USE_MINSTREL=y in your .config and rebuilding help? I made a comment regarding my experience with minstrel in /ticket/7363.html.

comment:35 Changed 8 years ago by Matt Turner <mattst88@…>

After upgrading to r22150, the situation is _much_ improved, but not totally fixed. After 4 days or so, the router died again.

I'll try 22152+ and report back.

comment:36 Changed 8 years ago by anonymous

I am currently running r22321 and there is nothing improved, the system is not usable at all. Every 2-3 hours the wireless connection dies and is only re-activatable by running wifi over cable connection, or doing a reboot.
This is the most unusable version I tried in the last 6 month.
Please make a version that is usable for these x86 ath9k combinations, I do not need fast speeds but it should be stable...

Thorsten

comment:37 Changed 8 years ago by nbd

Thorsten: what kind of hardware are you using?

comment:38 in reply to: ↑ 34 Changed 8 years ago by Alex

Sorry, I've had to test it without the minstrel rate selection first.
So now at least I can say the fixes improved my case very much. (My case was just an enormous slowdown after some days. Even if different from client to client, only an ap "reboot" helped. Now just the client with the Intel 965AGN needs a "reboot" to get full performance again after some time (so possibly just another bug but with the client driver). (The transfer rate always dropped to about 0.5MB/s from 5-7MB/s.))
Wanted to go to r22322 now, but as there are new fixes from today against the leak(s), I'm going to r22362.
(But I do not use it on x86, so I can't say anything about the bad comments on r22321.)

Replying to anonymous:

Just curious, does enabling CONFIG_PACKAGE_ATH9K_USE_MINSTREL=y in your .config and rebuilding help? I made a comment regarding my experience with minstrel in /ticket/7363.html.

comment:39 Changed 8 years ago by anonymous

I am using a alix 2d3 with an AR5008 wireless card

Thorsten

comment:40 Changed 8 years ago by Alex

I've tried the current trunk (for the first time with minstrel I think) and was able to reproduce the low (to nothing) transfer rate error really fast.

Seems that it can have to do with a 965AGN client going into hibernate?!

Because before the current version a real reboot of that client helped to repair his own rate, and never effected the other devices in the time itself was affected (since r22048, before they were affected until a router reboot).
But now the 965AGN client himself stays slow again until a router reboot.
And the working client was also influenced again, not forever as before r22048 but as long as i didn't reboot the 965AGN.

Really does not seem to have just worked accidentially for the last weeks, as I've tested it several times.

All connections were on 2,4GHz (because 5GHz also runs on this WNDR3700).
All N.
The 965AGN does not connect with HT40 on 2,4GHz (but with 5GHz..).
The Buffalo TX4 is connected with HT40.

Jan  1 00:00:10 OpenWrt user.notice rdate: Failed to sync with ntp.xs4all.nl
Jan  1 00:00:10 OpenWrt user.info kernel: cfg80211: Calling CRDA to update world regulatory domain
Jan  1 00:00:10 OpenWrt user.notice rdate: Failed to sync with tick.greyware.com
Jan  1 00:00:10 OpenWrt user.notice rdate: Failed to sync with ptbtime2.ptb.de
Jan  1 00:00:10 OpenWrt user.notice rdate: Failed to sync with ac-ntp1.net.cmu.edu
Jan  1 00:00:10 OpenWrt user.notice rdate: Failed to sync with cudns.cit.cornell.edu
Jan  1 00:00:10 OpenWrt user.notice rdate: Failed to sync with ptbtime1.ptb.de
Jan  1 00:00:10 OpenWrt user.notice rdate: Failed to sync with ptbtime3.ptb.de
Jan  1 00:00:10 OpenWrt user.notice rdate: Failed to sync with ac-ntp0.net.cmu.edu
Jan  1 00:00:10 OpenWrt user.notice rdate: No usable time server for wan found
Jan  1 00:00:10 OpenWrt user.notice kernel: SCSI subsystem initialized
Jan  1 00:00:11 OpenWrt user.info kernel: usbcore: registered new interface driver usbfs
Jan  1 00:00:11 OpenWrt user.info kernel: usbcore: registered new interface driver hub
Jan  1 00:00:11 OpenWrt user.info kernel: usbcore: registered new device driver usb
Jan  1 00:00:11 OpenWrt user.notice rdate: No usable time server for lan found
Jan  1 00:00:11 OpenWrt user.info kernel: cfg80211: World regulatory domain updated:
Jan  1 00:00:11 OpenWrt user.info kernel:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jan  1 00:00:11 OpenWrt user.info kernel:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jan  1 00:00:11 OpenWrt user.info kernel:     (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jan  1 00:00:11 OpenWrt user.info kernel:     (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jan  1 00:00:11 OpenWrt user.info kernel:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jan  1 00:00:11 OpenWrt user.info kernel:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jan  1 00:00:12 OpenWrt user.warn kernel: PCI: Enabling device 0000:00:11.0 (0000 -> 0002)
Jan  1 00:00:12 OpenWrt user.debug kernel: phy0: Selected rate control algorithm 'minstrel_ht'
Jan  1 00:00:12 OpenWrt user.info kernel: Registered led device: ath9k-phy0::radio
Jan  1 00:00:12 OpenWrt user.info kernel: Registered led device: ath9k-phy0::assoc
Jan  1 00:00:12 OpenWrt user.info kernel: Registered led device: ath9k-phy0::tx
Jan  1 00:00:12 OpenWrt user.info kernel: Registered led device: ath9k-phy0::rx
Jan  1 00:00:12 OpenWrt user.info kernel: phy0: Atheros AR9280 Rev:2 mem=0xb0000000, irq=48
Jan  1 00:00:12 OpenWrt user.warn kernel: PCI: Enabling device 0000:00:12.0 (0000 -> 0002)
Jan  1 00:00:12 OpenWrt user.debug kernel: phy1: Selected rate control algorithm 'minstrel_ht'
Jan  1 00:00:12 OpenWrt user.info kernel: Registered led device: ath9k-phy1::radio
Jan  1 00:00:12 OpenWrt user.info kernel: Registered led device: ath9k-phy1::assoc
Jan  1 00:00:12 OpenWrt user.info kernel: Registered led device: ath9k-phy1::tx
Jan  1 00:00:12 OpenWrt user.info kernel: Registered led device: ath9k-phy1::rx
Jan  1 00:00:12 OpenWrt user.info kernel: phy1: Atheros AR9280 Rev:2 mem=0xb0010000, irq=49
Jan  1 00:00:12 OpenWrt user.info kernel: NTFS driver 2.1.29 [Flags: R/O MODULE].
Jan  1 00:00:12 OpenWrt user.warn kernel: udf: Unknown symbol crc_itu_t
Jan  1 00:00:13 OpenWrt user.info kernel: PPP generic driver version 2.4.2
Jan  1 00:00:13 OpenWrt user.info kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Jan  1 00:00:13 OpenWrt user.info kernel: NET: Registered protocol family 24
Jan  1 00:00:13 OpenWrt user.info kernel: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Jan  1 00:00:13 OpenWrt user.info kernel: ar71xx-ehci ar71xx-ehci: Atheros AR71xx built-in EHCI controller
Jan  1 00:00:13 OpenWrt user.info kernel: ar71xx-ehci ar71xx-ehci: new USB bus registered, assigned bus number 1
Jan  1 00:00:13 OpenWrt user.info kernel: ar71xx-ehci ar71xx-ehci: irq 3, io mem 0x1b000000
Jan  1 00:00:13 OpenWrt user.info kernel: ar71xx-ehci ar71xx-ehci: USB 2.0 started, EHCI 1.00
Jan  1 00:00:13 OpenWrt user.info kernel: usb usb1: configuration #1 chosen from 1 choice
Jan  1 00:00:13 OpenWrt user.info kernel: hub 1-0:1.0: USB hub found
Jan  1 00:00:13 OpenWrt user.info kernel: hub 1-0:1.0: 2 ports detected
Jan  1 00:00:13 OpenWrt user.warn kernel: nf_conntrack version 0.5.0 (971 buckets, 3884 max)
Jan  1 00:00:14 OpenWrt user.info kernel: ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Jan  1 00:00:14 OpenWrt user.info kernel: ar71xx-ohci ar71xx-ohci: Atheros AR71xx built-in OHCI controller
Jan  1 00:00:14 OpenWrt user.info kernel: ar71xx-ohci ar71xx-ohci: new USB bus registered, assigned bus number 2
Jan  1 00:00:14 OpenWrt user.info kernel: ar71xx-ohci ar71xx-ohci: irq 14, io mem 0x1c000000
Jan  1 00:00:14 OpenWrt user.info kernel: usb usb2: configuration #1 chosen from 1 choice
Jan  1 00:00:14 OpenWrt user.info kernel: hub 2-0:1.0: USB hub found
Jan  1 00:00:14 OpenWrt user.info kernel: hub 2-0:1.0: 2 ports detected
Jan  1 00:00:14 OpenWrt user.info kernel: Registered led device: wndr3700:green:usb
Jan  1 00:00:14 OpenWrt user.info kernel: Initializing USB Mass Storage driver...
Jan  1 00:00:14 OpenWrt user.info kernel: usbcore: registered new interface driver usb-storage
Jan  1 00:00:14 OpenWrt user.info kernel: USB Mass Storage support registered.
Jan  1 00:00:15 OpenWrt user.info kernel: cfg80211: Calling CRDA for country: AT
Jan  1 00:00:15 OpenWrt user.info kernel: cfg80211: Regulatory domain changed to country: AT
Jan  1 00:00:15 OpenWrt user.info kernel:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jan  1 00:00:15 OpenWrt user.info kernel:     (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jan  1 00:00:15 OpenWrt user.info kernel:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jan  1 00:00:15 OpenWrt user.info kernel:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jan  1 00:00:15 OpenWrt user.info kernel:     (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
Jan  1 00:00:16 OpenWrt user.info kernel: device wlan0 entered promiscuous mode
Jan  1 00:00:16 OpenWrt user.info kernel: br-lan: port 2(wlan0) entering forwarding state
Jan  1 00:00:20 OpenWrt user.info kernel: device wlan0 left promiscuous mode
Jan  1 00:00:20 OpenWrt user.info kernel: br-lan: port 2(wlan0) entering disabled state
Jan  1 00:00:20 OpenWrt user.info kernel: device wlan0 entered promiscuous mode
Jan  1 00:00:20 OpenWrt user.info kernel: br-lan: port 2(wlan0) entering forwarding state
Jan  1 00:00:20 OpenWrt user.info kernel: device wlan1 entered promiscuous mode
Jan  1 00:00:20 OpenWrt user.info kernel: br-lan: port 3(wlan1) entering forwarding state
Jan  1 00:00:21 OpenWrt daemon.info hostapd: wlan0: STA 00:1d:73:c9:07:d1 IEEE 802.11: authenticated
Jan  1 00:00:21 OpenWrt daemon.info hostapd: wlan0: STA 00:1d:73:c9:07:d1 IEEE 802.11: associated (aid 1)
Jan  1 00:00:21 OpenWrt daemon.info hostapd: wlan0: STA 00:1d:73:c9:07:d1 WPA: pairwise key handshake completed (RSN)
Jan  1 00:00:25 OpenWrt user.info kernel: device wlan1 left promiscuous mode
Jan  1 00:00:25 OpenWrt user.info kernel: br-lan: port 3(wlan1) entering disabled state
Jan  1 00:00:25 OpenWrt user.info kernel: device wlan1 entered promiscuous mode
Jan  1 00:00:25 OpenWrt user.info kernel: br-lan: port 3(wlan1) entering forwarding state
Jan  1 00:00:25 OpenWrt user.info sysinit: Loading defaults
Jan  1 00:00:25 OpenWrt user.info sysinit: Loading synflood protection
Jan  1 00:00:26 OpenWrt user.info sysinit: Adding custom chains
Jan  1 00:00:26 OpenWrt user.info sysinit: Loading zones
Jan  1 00:00:27 OpenWrt user.info sysinit: Loading forwardings
Jan  1 00:00:27 OpenWrt user.info sysinit: Loading redirects
Jan  1 00:00:27 OpenWrt user.info sysinit: Loading rules
Jan  1 00:00:27 OpenWrt user.info sysinit: Loading includes
Jan  1 00:00:27 OpenWrt user.info sysinit: Optimizing conntrack
Jan  1 00:00:27 OpenWrt user.info sysinit: Loading interfaces
Jan  1 00:00:27 OpenWrt user.info firewall: info adding lan (br-lan) to zone lan
Jan  1 00:00:27 OpenWrt user.info firewall: info adding wan (eth1) to zone wan
Jan  1 00:00:28 OpenWrt authpriv.info dropbear[1575]: Running in background
Jan  1 00:00:28 OpenWrt user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Jan  1 00:00:28 OpenWrt daemon.info dnsmasq[1592]: started, version 2.55 cachesize 150
Jan  1 00:00:28 OpenWrt daemon.info dnsmasq[1592]: compile time options: IPv6 GNU-getopt no-DBus no-I18N DHCP TFTP
Jan  1 00:00:28 OpenWrt daemon.info dnsmasq[1592]: using local addresses only for domain lan
Jan  1 00:00:28 OpenWrt daemon.info dnsmasq[1592]: reading /tmp/resolv.conf.auto
Jan  1 00:00:28 OpenWrt daemon.info dnsmasq[1592]: using nameserver 192.168.0.1#53
Jan  1 00:00:28 OpenWrt daemon.info dnsmasq[1592]: using local addresses only for domain lan
Jan  1 00:00:28 OpenWrt daemon.info dnsmasq[1592]: read /etc/hosts - 1 addresses
Jan  1 00:00:28 OpenWrt user.info sysinit: setting up led WAN LED (green)
Jan  1 00:00:28 OpenWrt user.debug kernel: ar71xx-wdt: enabling watchdog timer
Jan  1 00:06:27 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:06:27 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 2)
Jan  1 00:06:27 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 WPA: pairwise key handshake completed (RSN)
Jan  1 00:09:58 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:09:58 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 2)
Jan  1 00:09:58 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 WPA: pairwise key handshake completed (RSN)
Jan  1 00:10:18 OpenWrt daemon.info hostapd: wlan0: STA 00:1d:73:c9:07:d1 WPA: group key handshake completed (RSN)
Jan  1 00:10:21 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: deauthenticated due to local deauth request
Jan  1 00:10:22 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:10:22 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 2)
Jan  1 00:10:24 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 WPA: pairwise key handshake completed (RSN)
Jan  1 00:14:23 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:23 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 2)
Jan  1 00:14:23 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 WPA: pairwise key handshake completed (RSN)
Jan  1 00:14:33 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:33 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:33 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:33 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:33 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:33 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: deauthenticated due to local deauth request
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:34 OpenWrt daemon.notice hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: did not acknowledge authentication response
Jan  1 00:14:34 OpenWrt daemon.notice hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: did not acknowledge authentication response
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:34 OpenWrt daemon.notice hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: did not acknowledge authentication response
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 1)
Jan  1 00:14:34 OpenWrt daemon.info hostapd: wlan1: STA 00:1f:3b:36:5e:67 IEEE 802.11: deauthenticated due to local deauth request
Jan  1 00:14:40 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:14:40 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 2)
Jan  1 00:14:42 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 WPA: pairwise key handshake completed (RSN)
Jan  1 00:17:34 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:17:34 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 2)
Jan  1 00:17:34 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 WPA: pairwise key handshake completed (RSN)
Jan  1 00:20:18 OpenWrt daemon.info hostapd: wlan0: STA 00:1d:73:c9:07:d1 WPA: group key handshake completed (RSN)
Jan  1 00:30:18 OpenWrt daemon.info hostapd: wlan0: STA 00:1d:73:c9:07:d1 WPA: group key handshake completed (RSN)
Jan  1 00:33:00 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:33:00 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 2)
Jan  1 00:33:02 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 WPA: pairwise key handshake completed (RSN)
Jan  1 00:35:27 OpenWrt authpriv.info dropbear[2011]: Child connection from 192.168.0.115:49215
Jan  1 00:35:35 OpenWrt authpriv.notice dropbear[2011]: password auth succeeded for 'root' from 192.168.0.115:49215
Jan  1 00:37:17 OpenWrt authpriv.info dropbear[2022]: Child connection from 192.168.0.110:49219
Jan  1 00:37:23 OpenWrt authpriv.notice dropbear[2022]: password auth succeeded for 'root' from 192.168.0.110:49219
Jan  1 00:38:26 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: authenticated
Jan  1 00:38:26 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 IEEE 802.11: associated (aid 2)
Jan  1 00:38:26 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 WPA: pairwise key handshake completed (RSN)
Jan  1 00:38:39 OpenWrt authpriv.info dropbear[2011]: exit after auth (root): error reading: Connection reset by peer
Jan  1 00:39:24 OpenWrt authpriv.info dropbear[2048]: Child connection from 192.168.0.115:49222
Jan  1 00:39:30 OpenWrt authpriv.notice dropbear[2048]: password auth succeeded for 'root' from 192.168.0.115:49222
Jan  1 00:40:18 OpenWrt daemon.info hostapd: wlan0: STA 00:1d:73:c9:07:d1 WPA: group key handshake completed (RSN)
Jan  1 00:40:20 OpenWrt daemon.info hostapd: wlan0: STA 00:1f:3b:36:5e:67 WPA: group key handshake completed (RSN)

Don't know if it should be the same case anymore.. . But the fixes seemed to have to do with it.

comment:41 Changed 8 years ago by anonymous

Hi guys,
I observed a new problem, with the newest trunk I am now at least connected for over 10 hours without getting disconnected. The bad news are that the connection is sometimes getting unbelievable slow ...

[  3] local 192.168.1.212 port 61017 connected with 192.168.1.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  1.89 MBytes  1.57 Mbits/sec
macbook:~ thorsten$ iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 64.2 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.212 port 61039 connected with 192.168.1.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-11.0 sec    112 KBytes  83.6 Kbits/sec
macbook:~ thorsten$ iperf -c 192.168.1.1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 64.2 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.212 port 61046 connected with 192.168.1.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.6 sec  1.16 MBytes    924 Kbits/sec

Tell me If I can help somehow with providing logfiles or using different settings to find out whats going on here.

Thorsten

comment:42 follow-up: Changed 8 years ago by anonymous

I'm using a WNDR3700 (two ath9k interfaces), currently with r22390, and I see strange wifi problems that may be related to the bugs here. I get the same behavior with CONFIG_PACKAGE_ATH9K_USE_MINSTREL enabled or not. My client is using an Intel 5300 (agn) adapter, with Ubuntu 10.10 (currently kernel 2.6.35-rc). If I enable wireless N on the router's 5GHz radio:

config wifi-device  radio1                          
        option type     mac80211                    
        option channel  153                         
        option macaddr  11:22:33:44:55:66          
        option hwmode   11na                        
        option country  US                          
        option htmode   HT40-                       
        list ht_capab   SHORT-GI-40                 
        list ht_capab   TX-STBC                     
        list ht_capab   RX-STBC1                    
        list ht_capab   DSSS_CCK-40
                                          
config wifi-iface                         
        option device   radio1            
        option network  lan               
        option mode     ap                
        option ssid     zzz     
        option encryption psk2            
        option key      'xxx yyy'

then I almost instantly have connectivity problems on the client -- for example I am able to ping the router but not ping google.com, I can't reach various web sites, etc.

I'm pretty sure this is router/openwrt-related because if I change nothing except the "hwmode 11na" to "hwmode 11a" then everything is completely stable for days at a time and I have no trouble with pings etc.

Anyone seen anything similar to this?

comment:43 in reply to: ↑ 42 Changed 8 years ago by anonymous

As I'm also having problems with an intel agn I'll try what happens when I disable n on 5GHz.

Replying to anonymous:

I'm using a WNDR3700 (two ath9k interfaces), currently with r22390, and I see strange wifi problems that may be related to the bugs here. I get the same behavior with CONFIG_PACKAGE_ATH9K_USE_MINSTREL enabled or not. My client is using an Intel 5300 (agn) adapter, with Ubuntu 10.10 (currently kernel 2.6.35-rc). If I enable wireless N on the router's 5GHz radio:

config wifi-device  radio1                          
        option type     mac80211                    
        option channel  153                         
        option macaddr  11:22:33:44:55:66          
        option hwmode   11na                        
        option country  US                          
        option htmode   HT40-                       
        list ht_capab   SHORT-GI-40                 
        list ht_capab   TX-STBC                     
        list ht_capab   RX-STBC1                    
        list ht_capab   DSSS_CCK-40
                                          
config wifi-iface                         
        option device   radio1            
        option network  lan               
        option mode     ap                
        option ssid     zzz     
        option encryption psk2            
        option key      'xxx yyy'

then I almost instantly have connectivity problems on the client -- for example I am able to ping the router but not ping google.com, I can't reach various web sites, etc.

I'm pretty sure this is router/openwrt-related because if I change nothing except the "hwmode 11na" to "hwmode 11a" then everything is completely stable for days at a time and I have no trouble with pings etc.

Anyone seen anything similar to this?

comment:44 Changed 8 years ago by anonymous

I still have the problems with the current trunk. When I remove the N-speed activating line "option hwmode 11ng" in /etc/config/wireless the problems are gone except of speed drops from time to time. The very bad thing is that the speed is very low (10-20mbit, regular G-speed). So the disconnecting issue is related to the N-mode??

Thorsten

comment:45 Changed 8 years ago by anonymous

Hi again!
So even with the most recent trunk version I have the problem. And I have the feeling that it is mach worse than it was maybe 6 month ago. After connecting with N-speed I have now disconnects every 5-20 minutes. Sometimes as described earlier it self-reconnects, sometimes you have to do it manually and sometimes even this is not possible, so you have to connect via wire and make an "wifi" or reboot the machine. When running the machine in G-mode it is stable but sometimes the speed drops extremely, so that for a few seconds sometimes minutes everything is nearly unusable. Taking everything together this machine with this configuration is not usable as a wireless router!
So what should I do now, I just want to use my router, not less and not more. Why is nobody fixing this, is it really that hart or are only a few people affected so the problem gets ignored?
Is there any wireless card known to work perfect/stable even a G-speed card would be okay for me as long it is working stable and fast enough to use it?

I wish u all a nice weekend,
Thorsten

comment:46 follow-up: Changed 8 years ago by nbd

This isn't really one specific problem that was discussed here in the ticket. It was a large number of different bugs with similar symptoms, which I reduced to a much smaller number of bugs.
Currently it seems that you're one of the few people still affected by this, I haven't seen many other reports of this anymore.
One thing you could do to help tracking this down is: enable the CONFIG_PACKAGE_ATH_DEBUG option in your config, rmmod ath9k, insmod ath9k debug=8, then set up an AP, pull the output of logread over the network (wired!) into a file, then wait for a disconnect to happen.

comment:47 follow-up: Changed 8 years ago by nbd

Oh, and send me the file afterwards ;)

Changed 8 years ago by marc

ath debug output

comment:48 in reply to: ↑ 47 Changed 8 years ago by anonymous

Attached log.txt
Contains logoutput with "ath9k debug=8"
DIR-825 r22442

Replying to nbd:

Oh, and send me the file afterwards ;)

comment:49 follow-up: Changed 8 years ago by nbd

the attached debug log indicates strong interference, possibly causing stuck beacons.
i just reworked noise floor limit handling and stuck beacon recovery in r22460.

this should hopefully take care of this problem, please test.

comment:50 in reply to: ↑ 49 Changed 8 years ago by Alex

Okay, so I will test r22461.
The last version (r22459) was, like said earlier, definitely not better than r22048 on my issue with the Intel 4965AGN. As I'm not alone: My slow to nothing gets transfered or reboot issue is reproducable instantly with the Intel AGN (on Windows) with the current builds. And as someone before said he has the problem and uses an (other) AGN on Linux, propably the combination of AGN (client) and ath9k (ap) should be focused. Before also other clients were effected from several bugs/effects, this is still better.
Deactivation of 5GHz or only n on 5GHz didn't change anything for me.
I will also add a log soon (if the issue still persists (had not compiled r22459 with ath_debug)).

Thank you for the great continuous support!

Alex

Replying to nbd:

the attached debug log indicates strong interference, possibly causing stuck beacons.
i just reworked noise floor limit handling and stuck beacon recovery in r22460.

this should hopefully take care of this problem, please test.

comment:51 Changed 8 years ago by anonymous

I am still getting issues on my DIR-825 with r22461. Wireless clients will lose internet connection (iPad, Windows 7 with Intel 1000 BGN, iPhone 3GS). The strange thing is clients only have issues with WAN. They are able to pull up the router's LuCi configuration page, but websites do not work. Wired clients continue to work fine for both WAN and LAN.

Changed 8 years ago by Alex

initiated file transfer causes connection "loss" (timeouts instead of 8ms ping time)

Changed 8 years ago by Alex

initiated file transfer causes connection "loss" (timeouts instead of 8ms ping time)

comment:52 in reply to: ↑ 46 Changed 8 years ago by anonymous

As I didn't get any changes when running with debug=8 I debugged with 0xffffffff. (The next time we would know which level will be right ;-) )
I connect with the AGN Adapter, I monitor with pings, I start a file transfer (windows "cifs"), pings are not coming back, file transfer goes extremely slow in the best case.
No problem if I connect the same laptop over its ethernet port which goes to a Buffalo WLI-TX4-AG300N connected to the same ap.
It was not so easy to reproduce this before. It was bad, got better, and now its even bader than before.

Replying to nbd:

This isn't really one specific problem that was discussed here in the ticket. It was a large number of different bugs with similar symptoms, which I reduced to a much smaller number of bugs.
Currently it seems that you're one of the few people still affected by this, I haven't seen many other reports of this anymore.
One thing you could do to help tracking this down is: enable the CONFIG_PACKAGE_ATH_DEBUG option in your config, rmmod ath9k, insmod ath9k debug=8, then set up an AP, pull the output of logread over the network (wired!) into a file, then wait for a disconnect to happen.

comment:53 follow-up: Changed 8 years ago by nbd

Wait a minute... Clients lose WAN access, but can still continue to access internal web pages? That definitely doesn't sound like a bug in the wireless driver to me.

Even if they can still access stuff from the LAN ports, that sounds more like a switch driver problem to me.

Please try the patch from https://dev.openwrt.org/attachment/ticket/7637/rtl8366xx_enable_learning.patch and see if it helps.

comment:54 in reply to: ↑ 53 Changed 8 years ago by Alex

Just to don't mix up - I don't use the wan port. (And it works with other WLAN clients so.. .)
Did you see anything in my debug log(s)?
I'm really interested to help, because at the moment the effect is so strong that it's not usable. Which I think is good for the debug ;-).

Replying to nbd:

Wait a minute... Clients lose WAN access, but can still continue to access internal web pages? That definitely doesn't sound like a bug in the wireless driver to me.

Even if they can still access stuff from the LAN ports, that sounds more like a switch driver problem to me.

Please try the patch from https://dev.openwrt.org/attachment/ticket/7637/rtl8366xx_enable_learning.patch and see if it helps.

comment:55 follow-up: Changed 8 years ago by nbd

@Alex: Your debug logs were not really usable, as they contain too much stuff and only cover a short period of time. What kind of wifi card are you using on the client?
Also, if you're using an intel card, try switch off 802.11n and see if the problem is still there.

comment:56 in reply to: ↑ 55 Changed 8 years ago by Alex

The Client which corrupts the connection is an Intel 4965AGN.
It is enough to disable n on this client. The connection then does not have the problem. But other clients also don't have it on n. This client had it only after some time and so on on older builds.
In the short period of the log the file transfer starts and the connection looses its usability. So the problem starts in this time frame.
Sorry for the much stuff, I hoped we can filter out which debug option I should use in future for testing and seeing only the necessary info.
To replicate: (Its much easier to recognize with minstrel in the last time, there it happens instantly now)
Use n (here channel 6) on (at least) the WNDR3700.
Connect with an Intel AGN (at least the 4965) to 2,4GHz n.
Then I just try to get a shared file from the wired side to my wireless client, and as soon as the transfer would start the connection gets slow and unresponsive as hell.

Replying to nbd:

@Alex: Your debug logs were not really usable, as they contain too much stuff and only cover a short period of time. What kind of wifi card are you using on the client?
Also, if you're using an intel card, try switch off 802.11n and see if the problem is still there.

comment:57 Changed 8 years ago by anonymous

Ok, maybe it is to early to say that my problem is solved, but the last 20 hours I had no disconnects, yeah!!! So after upgrading to r22462 everything runs fine, no speed issues in N-mode and till now no disconnects!
What hast changed during the last revisions??

Thorsten

comment:58 Changed 8 years ago by nbd

  • Resolution set to fixed
  • Status changed from reopened to closed

As I mentioned before, I did a rework of stuck beacon handling and noise floor calibration. Maybe your setup just had more interference than others, and that may have caused the issues you were seeing.

With those changes, the driver gets much better at dealing with stuff like that ;)

Since this ticket refers to so many different issues, most of which were fixed already, I'll close it now. If any of you still have stability issues, please open up a new ticket with a detailed problem description.

comment:59 Changed 8 years ago by Matt Turner <mattst88@…>

r22444 was as bad as any revision I've ever tried. I just flashed r22476. Good god I hope this fixes it.

comment:60 Changed 8 years ago by anonymous

I have to revert my optimism, the disconnects are still there. After 24 hours it happened the first time. Now it happens again from minutes to hours with regular constance. So the cause seems to be still unfixed. Even with the newest trunk I have the problem. What the hell is causing this?

Thorsten

comment:61 Changed 7 years ago by anonymous

I have the same problem, after some time, the disconnected happens again (my router is wndr3700).

The different is when I login(by lan), kill hostapd, and run "wifi", it works again, doesn't need reboot the router.

comment:62 Changed 7 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

I have the same issue on my WNDR3700 with OpenWrt 10.03.1, 10.03.1-rc1 and 10.03.1-rc2. Fixed it temporarily by disabling 11n.

comment:63 Changed 7 years ago by jow

Those reports are of no help, sorry. Please provide hostapd debug logs, client logs if applicable, wireless configuration, wireless client info like model/chipset/driver and anything else thats applicable here.

Also please create a *new* ticket with this information.

comment:64 Changed 7 years ago by nbd

  • Resolution set to fixed
  • Status changed from reopened to closed

you might want to try -rc3 (or even better: current backfire svn)
And as jow pointed out: open a new ticket if you still have issues afterwards - this ticket is useless now, too much misinformation.

comment:65 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.