I seem to be getting really slow TX data speeds on my network. The iw tool shows that I'm mostly at MCS0 / MCS1 with 6.0MBit/s speeds or so. Trying to ping google.com takes around 4/5 seconds for the DNS resolution to take place. Putting my AP into 5GHz mode or using 11n_disable=1 seems to fix it. All my other devices work fine with this AP, which makes me think it's an issue with the iwlwifi drivers. My network device is a Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 96) My AP is a Motorola SBG6580, with firmware SBG6580-6.5.2.0-GA-06-077-NOSH, if that helps at all. I'm happy to give more info if needed.
Can you please try this: https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=43d826ca5979927131685cc2092c7ce862cb91cd thank you.
It doesn't seem to help, unfortunately.
Are you using 40Mhz or 20Mhz? if you are using 40Mhz, can you please try to force your AP to 20Mhz?
It's set to 20Mhz I'm still having issues. Here are the options I have set, if it helps any. http://i.imgur.com/3U6hPgx.png
out of curiosity, can you please disable STBC? Also, please paste / attach your dmesg output. I'd like to see if this is not the same issue as another open bug.
This is all I have. [ 34.738955] wlp3s0: deauthenticating from f8:35:dd:00:4a:ff by local choice (Reason: 3=DEAUTH_LEAVING) [ 34.784634] cfg80211: Calling CRDA to update world regulatory domain [ 34.804754] cfg80211: World regulatory domain updated: [ 34.804758] cfg80211: DFS Master region: unset [ 34.804759] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 34.804761] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 34.804763] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 34.804764] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [ 34.804765] cfg80211: (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A) [ 34.804767] cfg80211: (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 34.804768] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 34.804769] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [ 34.804771] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [ 34.805088] cfg80211: Calling CRDA for country: US [ 34.814603] cfg80211: Regulatory domain changed to country: US [ 34.814607] cfg80211: DFS Master region: FCC [ 34.814608] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 34.814610] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A) [ 34.814612] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 1700 mBm), (N/A) [ 34.814613] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2300 mBm), (0 s) [ 34.814615] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A) [ 34.814616] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) [ 37.013542] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S [ 37.020003] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [ 37.119508] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready [ 40.782949] wlp3s0: authenticate with f8:35:dd:00:4a:ff [ 40.793427] wlp3s0: send auth to f8:35:dd:00:4a:ff (try 1/3) [ 40.797078] wlp3s0: authenticated [ 40.798731] wlp3s0: associate with f8:35:dd:00:4a:ff (try 1/3) [ 40.802640] wlp3s0: RX AssocResp from f8:35:dd:00:4a:ff (capab=0x411 status=0 aid=2) [ 40.830824] wlp3s0: associated [ 40.830870] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
Hm... This looks more the less healthy.
That's why I'm so confused. If there's any other information I can give or patches I can try, please let me know.
please run with module parameter: debug=0xC0800000 I'll try to see if I see something bad. Note that it will be very chatty. I'll probably need the kern.log and not dmesg only (to have more history). Thank you.
Here's the debug log: http://funny.computer/cloud/Linux/wifi_debug Also, as an unrelated bug, when I tried to re-enable 11n_disabled=true, it failed and I got this in my logs: http://funny.computer/cloud/Linux/modprobe_fail Should I file it separately?
for the second bug - I don't really see how it is related to iwlwifi - at least we don't appear in the stack. Looking at your first log.
Tons of SHORT_LIMIT which means that we can't get our RTS responded... Are you on 2.4GHz or 5.2GHz?
According to my AP's control panel, I'm on 2.4GHz.
Created attachment 143861 [details] disable protection Hi, can you please try this? Thank you.
Do we have some news here?
Sorry, I've been travelling for the past week and have been away from my AP. I should be able to test your patch sometime next week. I'll let you know then.
The patch did not have any effect. If you need any other debugging information, please let me know.
weird... another user told me that my patch was so botched that it broke everything...
*** Bug 83881 has been marked as a duplicate of this bug. ***
Came here to say that I also experience this issue (Reported bug 83881, duplicate), but only on WPA2-Enterprise networks at my school, and only in areas that have a high density of wireless APs. According to information from IT, the APs use patch antennas to shrink down cell size, but are otherwise identical in configuration to other WPA2-Enterprise APs at my school that I have no trouble connecting to. Rather than just a slow connection, I lose all connectivity -- even if I do manage to associate and DHCP the network, I can't make any outgoing connections, they simply time out or report that the destination host is unreachable. Intel Advanced-N 6200 2.4/5GHz, archlinux with kernel 3.16.1. As with the others, 11n_disable makes everything work, albeit slowly. Perhaps the driver is having trouble choosing and sticking to an AP given many choices? Or in the words of our IT group, receiving "an unexpected multipath result"? IT gave me some additional diagnosing to try, and I'll report back once I finish.
Can someone try to disable power save? sudo iw wlan0 set power_save off Someone reported that this helped. Thanks
Power save off didn't change anything. Will test out your kernel patch and report back.
Created attachment 149541 [details] Packet capture showing tons of RTS with no response On the same not getting replies to the RTS, I took this packet dump today and observed the same.
Yes - I had this same observation from someone else. Sad news, because in this case, it is clearly a firmware bug and we have no support from the firmware for these devices. Other users noticed that disabling power save helps, so I will submit the patch (I already did) - but I am afraid there isn't much I can do about the 11n_disable=1 problem...
You can try this: https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=ff36e3756cc8abb42608ceed4d173d128ac4c9ad But I am afraid that I won't be able to do much for this issue. If the patch above doesn't fix this bug (and I don't think it will), I'll close this bug as will not fix unfortunately.
This bug will not be fixed. No firmware support anymore.