Description of problem: It often fails to connect to wireless networks. Sometimes it does, but then gets disconnected. This is a 2nd generation Intel Macbook with a AR5008 card. Used to work fine on earlier kernels. eg., the ones in Fedora 15. Version-Release number of selected component (if applicable): kernel-3.2.9-1.fc16.x86_64
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
I'm running a MacBook 2,1 with the same hardware. I'm also having the same issues. I'm currently running the kernel 3.5.0-2.fc17.x86_64 and I have the problem. I can't explain why, but the bug happened after my router went down for a moment (because of a network failure in the whole area). When it was back up, it was misconfigured. When I had reconfigured it, I could not connect anymore. I just tried "iwconfig wlan0 power off" and it seems to improve a bit, but not by much. Often, I can't connect. Here is an example of a dmesg log of that case: [ 137.930185] wlan0: authenticate with be:bf:20:5d:45:f4 [ 137.932415] wlan0: send auth to be:bf:20:5d:45:f4 (try 1/3) [ 138.133051] wlan0: send auth to be:bf:20:5d:45:f4 (try 2/3) [ 138.334037] wlan0: send auth to be:bf:20:5d:45:f4 (try 3/3) [ 138.535028] wlan0: authentication with be:bf:20:5d:45:f4 timed out [ 138.951511] ath: phy0: Failed to stop TX DMA, queues=0x001! [ 141.865396] wlan0: authenticate with be:bf:20:5d:45:f4 [ 141.868854] wlan0: direct probe to be:bf:20:5d:45:f4 (try 1/3) [ 142.069047] wlan0: direct probe to be:bf:20:5d:45:f4 (try 2/3) [ 142.270046] wlan0: direct probe to be:bf:20:5d:45:f4 (try 3/3) [ 142.471025] wlan0: authentication with be:bf:20:5d:45:f4 timed out [ 153.410857] wlan0: authenticate with be:bf:20:5d:45:f4 [ 153.413482] wlan0: direct probe to be:bf:20:5d:45:f4 (try 1/3) [ 153.614050] wlan0: direct probe to be:bf:20:5d:45:f4 (try 2/3) [ 153.815045] wlan0: direct probe to be:bf:20:5d:45:f4 (try 3/3) [ 154.016043] wlan0: authentication with be:bf:20:5d:45:f4 timed out [ 157.035455] wlan0: authenticate with be:bf:20:5d:45:f4 [ 157.038578] wlan0: direct probe to be:bf:20:5d:45:f4 (try 1/3) [ 157.239044] wlan0: direct probe to be:bf:20:5d:45:f4 (try 2/3) [ 157.440065] wlan0: direct probe to be:bf:20:5d:45:f4 (try 3/3) [ 157.641050] wlan0: authentication with be:bf:20:5d:45:f4 timed out When I can connect, I don't always keep the connections. Sometimes pings have no packet loss, sometimes it has as much as 80% packet loss (when I can ping at all). When I disconnect, my log file registers nothing but: [ 958.674492] cfg80211: Calling CRDA to update world regulatory domain [ 958.687506] cfg80211: World regulatory domain updated: ... [ 958.687535] cfg80211: Calling CRDA for country: FR [ 958.692257] cfg80211: Regulatory domain changed to country: FR ... With then the authenticate lines, just as before. After a few failures, I get prompted for the WPA key again, until I am tried of this. I tried modprobe ath9k nohwcrypt=1 but I don't get better results. Using modinfo ath9k, i noticed that there ws a debug option I could specify. Would it be helpful to set it to some value? Note: this is not the first time I get this problem, but it doesn't seem to appear all the time.
I tried modprobe ath9k debug=0x82 I could then connect to the AP. Here is a log of a successfull connection: [ 1758.547345] wlan0: authenticate with be:bf:20:5d:45:f4 [ 1758.550405] wlan0: send auth to be:bf:20:5d:45:f4 (try 1/3) [ 1758.565787] wlan0: authenticated [ 1758.568129] wlan0: associating with AP with corrupt beacon [ 1758.569066] wlan0: associate with be:bf:20:5d:45:f4 (try 1/3) [ 1758.600580] wlan0: RX AssocResp from be:bf:20:5d:45:f4 (capab=0x411 status=0 aid=1) [ 1758.600665] wlan0: associated [ 1758.601200] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready No difference with or without debug=0x82, and the connection is still unstable. I wonder what the corrupt beacon is.
The problem seems the same as in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1031332 In particular, I have the same wireless router: "Freebox v5". And the problem appeared when its configuration was reset. On the router interface, the network protection is set to "WPA (TKIP)". With "WPA (TKIP + AES)" and remove/reinserting the ath9k module, operation seems a bit better. I can't really tell, as network operations are still a bit slow. But at least I seem to keep the connection. I tried with the nohwcrypt=1 option but I couldn't connect. With "WPA (AES/CCMP)" or "WPA (AES)" I seem to get a way better connection. I can download normally and don't get disconnected. It seems that TKIP is responsible for that.
# Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
This might sound silly, and maybe it is... but have you tried with a simple password, with only plain letters for example? I have basically the same set up (Freebox v5 + MBP 3,1 + AR5008/5418) and getting rid of the fancy characters seems to ease things of quite a bit. At first I thought it was related to the encryption type (AES, TKIP and friends) but I still can't connect with a 'complicated' password. Nothing I can say regarding potential disconnects since I don't rely on/use wifi on a regular basis. It would be good to test and see if the problem does not come from the ISP instead.
Just got my hands on the device, will give it a try soonest I can and let you know.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.