Description of problem: On my Lenovo T440s laptop with an Intel Corporation Wireless 7260 (rev 83) wireless card, I cannot connect to the 5GHz SSID of my AirPort Extreme. I have the newest 802.11ac model of AirPort, running the most current firmware. The error I'm seeing is "AP {AP's MAC} changed bandwidth in a way we can't support - disconnect" I do have two of these APs, one extending the other wirelessly, but I'm about 10 feet away from the primary device when I see these errors. Version-Release number of selected component (if applicable): Fedora 20, kernel 3.12.10-300.fc20.x86_64 How reproducible: Every time Steps to Reproduce: 1. Attempt to connect to the 5GHz SSID of my network 2. Many attempts, but all fail, producing an error in /var/log/messages 3. Actual results: This is a connection attempt from /var/log/messages: Feb 14 11:11:07 localhost kernel: [ 218.041243] cfg80211: Calling CRDA to update world regulatory domain Feb 14 11:11:07 localhost kernel: [ 218.042841] cfg80211: World regulatory domain updated: Feb 14 11:11:07 localhost kernel: [ 218.042845] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Feb 14 11:11:07 localhost kernel: [ 218.042846] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Feb 14 11:11:07 localhost kernel: [ 218.042848] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Feb 14 11:11:07 localhost kernel: [ 218.042849] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Feb 14 11:11:07 localhost kernel: [ 218.042850] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Feb 14 11:11:07 localhost kernel: [ 218.042852] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Feb 14 11:11:07 localhost NetworkManager[2088]: <info> (wlp3s0): supplicant interface state: completed -> disconnected Feb 14 11:11:07 localhost NetworkManager[2088]: <info> (wlp3s0): supplicant interface state: disconnected -> scanning Feb 14 11:11:11 localhost kernel: [ 221.713266] wlp3s0: authenticate with 90:72:40:11:f8:05 Feb 14 11:11:11 localhost kernel: [ 221.715855] wlp3s0: send auth to 90:72:40:11:f8:05 (try 1/3) Feb 14 11:11:11 localhost kernel: [ 221.716792] wlp3s0: authenticated Feb 14 11:11:11 localhost kernel: [ 221.717824] wlp3s0: associate with 90:72:40:11:f8:05 (try 1/3) Feb 14 11:11:11 localhost NetworkManager[2088]: <info> (wlp3s0): supplicant interface state: scanning -> associating Feb 14 11:11:11 localhost kernel: [ 221.719164] wlp3s0: RX AssocResp from 90:72:40:11:f8:05 (capab=0x1011 status=0 aid=5) Feb 14 11:11:11 localhost kernel: [ 221.721527] wlp3s0: associated Feb 14 11:11:11 localhost kernel: [ 221.721584] cfg80211: Calling CRDA for country: US Feb 14 11:11:11 localhost kernel: [ 221.723349] cfg80211: Regulatory domain changed to country: US Feb 14 11:11:11 localhost kernel: [ 221.723351] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Feb 14 11:11:11 localhost kernel: [ 221.723353] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) Feb 14 11:11:11 localhost kernel: [ 221.723354] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Feb 14 11:11:11 localhost kernel: [ 221.723355] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Feb 14 11:11:11 localhost kernel: [ 221.723356] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Feb 14 11:11:11 localhost kernel: [ 221.723357] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Feb 14 11:11:11 localhost kernel: [ 221.723358] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Feb 14 11:11:11 localhost kernel: [ 221.723359] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm) Feb 14 11:11:11 localhost NetworkManager[2088]: <info> (wlp3s0): supplicant interface state: associating -> completed Feb 14 11:11:11 localhost kernel: [ 221.744646] wlp3s0: AP 90:72:40:11:f8:05 changed bandwidth, new config is 5660 MHz, width 2 (5670/0 MHz) Feb 14 11:11:11 localhost kernel: [ 221.744649] wlp3s0: AP 90:72:40:11:f8:05 changed bandwidth in a way we can't support - disconnect Feb 14 11:11:11 localhost NetworkManager[2088]: <warn> Connection disconnected (reason -3) Expected results: Connection is made to the 5GHz network. Additional info:
Do you have the latest linux-firmware package installed? That contains updated firmware for these devices and while it might not be related to your issue at all, there are other things that the firmware update fixes.
Yum doesn't see any updates for my system at the moment. Rpm shows that this version is installed: linux-firmware-20140131-35.gitd7f8a7c8.fc20.noarch
> changed bandwidth, new config is 5660 MHz, width 2 (5670/0 MHz) > changed bandwidth in a way we can't support - disconnect Either AP send us wrong channel parameters or we do something wrong when interpreting them (0 MHz looks wrong, but this actually should be fine if 11ac 80+80 channel is not used). Gary, please reproduce the problem, then do "dmesg > dmesg.txt" and attach dmesg.txt file here. Additionally attach "iw phy" output.
> Fedora 20, kernel 3.12.10-300.fc20.x86_64 Firmware is updated, but is worth to try if 3.13 kernel helps too. It include various 7260 fixes and use new iwlwifi-7260-8.ucode (earlier kernels use -7.ucode) 3.13.3 should be available from updates-testing repo , if not it can be downloaded from koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=498256
I updated to the newer kernel from the regular production repos and the problem still happens: # uname -a Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 SMP Fri Feb 14 19:08:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux I'm attaching my dmesg output and the output of iw phy.
Created attachment 865053 [details] dmesg output
Created attachment 865054 [details] iw phy output
Not that it appears to make any difference, but I've reconfigured the setup on my wireless network. Now the second Extreme does not extend the first wirelessly, they are both plugged into an Ethernet switch.
There is some upstream discussion about the topic: https://bugzilla.kernel.org/show_bug.cgi?id=70881 Does "sudo mv /sbin/crda /sbin/crda.disabled" help with the issue for you ?
I *swear* I didn't update anything relevant to this issue, but it suddenly started working. I updated and put the newest kernel on, and it still connects properly. If the problem recurs, I'll try disabling the daemon and reopen the bug.
Is possible that AP stop changing bandwidth after we associate.