Description of problem: In about the last 6 months I had noticed this adapter being choosy about which networks it would connect to easily, I thought is it may have been the card but lived with it until recently. This card will no longer connect to any network I select at all with the error below and times out. I updated recently from FedoraCore 29 to 30 and have tried a 2nd card which is brand new and I get the same results. I am currently using a USB dongle ( 2.4 ) to get by. This looks to be a driver / firmware issue I am sure if I use an older install and or windows it would seem that these cards would work flawlessly ( I will test this ). The error from WPA Supplicant is: wpa_supplicant[1237]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Version-Release number of selected component (if applicable): Latest ( not sure what the release number is ) How reproducible: Very easy as its instantaneous on every connection attempt Steps to Reproduce: 1. Just try and connect to any wireless network 2.4G or 5G 2. 3. Actual results: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Expected results: Connect to any 2.4G or 5G Access Points. Additional info: The card in question is: Intel Corporation Centrino Ultimate-N 6300 Firmware, iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm Output from dmesg: [ 115.603574] wlp3s0: send auth to 5c:b0:66:14:25:9a (try 1/3) [ 115.913870] wlp3s0: authenticated [ 115.914506] wlp3s0: associate with 5c:b0:66:14:25:9a (try 1/3) [ 115.915807] wlp3s0: RX AssocResp from 5c:b0:66:14:25:9a (capab=0x411 status=0 aid=1) [ 115.918315] wlp3s0: associated [ 115.918907] wlp3s0: deauthenticating from 5c:b0:66:14:25:9a by local choice (Reason: 3=DEAUTH_LEAVING)
I tested with a live distro running kernel 4.15 ( Linux Mint ) and the card works on both 2.4 and 5 Ghz.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs. Fedora 30 has now been rebased to 5.2.9-200.fc30. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31. If you experience different issues, please open a new bug report for those.
My statis has not changed with this upgrade, Info ( messages log ): 2.4G connection attempt ( wpa2 ) Aug 21 06:13:35 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:13:36 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:13:37 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:13:38 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:13:39 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:13:40 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:13:41 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:13:42 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:13:43 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 5G connection attempt ( wpa2 ) Aug 21 06:14:17 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:14:18 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:14:19 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:14:20 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:14:21 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:14:22 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:14:23 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:14:24 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Aug 21 06:14:25 localhost wpa_supplicant[1234]: wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 Adapter Info [ 6.747734] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 6.748231] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-6.ucode failed with error -2 [ 6.748407] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-5.ucode failed with error -2 [ 6.749716] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm [ 6.856495] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled [ 6.856497] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled [ 6.856498] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [ 6.856500] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74 Kernel Linux localhost.localdomain 5.2.9-200.fc30.x86_64 #1 SMP Fri Aug 16 21:37:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
As a minro addition to the adapter information ( this is probably important ), [ 7.050677] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [ 7.069943] iwlwifi 0000:03:00.0 wlp3s0: renamed from wlan0 after which is a large number of these, [ 9.613182] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1 [ 9.857116] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1 [ 9.984140] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1 [ 10.236378] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
From a response I got from Luca at Intel on this here is his feedback, This error is -EINVAL, which means that the driver is not recognizing a parameter passed to it. It's hard to tell exactly what is causing that without further investigation. Are you able to compile the kernel and do some tests? One way you could do it is to replace the -EINVAL with a line number, so we can try to see where the invalid parameter error is coming from. Doing something like this: http://pastebin.coelho.fi/03fa29d951db5405.txt Then the returned error should correspond to a line number on the driver. Hope this helps to resolve this one..
(In reply to Nigel Sollars from comment #5) > Actual results: > wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 this reminds me of a similar bugzilla I've seen some weeks ago (bz1703745). > From a response I got from Luca at Intel on this here is his feedback, > > This error is -EINVAL, which means that the driver is not recognizing a > parameter passed to it. It's hard to tell exactly what is causing that > without further investigation. can you please try temporarily turning off wifi address randomization? $ sudo nmcli device modify wlp3s0 wifi.mac-address-randomization never and then retry? thanks! -- davide
After running the command I receive, Error: Reading applied connection from device 'wlp3s0' (/org/freedesktop/NetworkManager/Devices/3) failed: Device is not activated
For completeness, [ 7.110973] iwlwifi 0000:03:00.0 wlp3s0: renamed from wlan0 [root@localhost ~]# systemctl status NetworkManager.service ● NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2019-08-21 18:16:03 EDT; 40s ago Docs: man:NetworkManager(8) Main PID: 1101 (NetworkManager) Tasks: 3 (limit: 4915) Memory: 12.3M CGroup: /system.slice/NetworkManager.service └─1101 /usr/sbin/NetworkManager --no-daemon Aug 21 18:16:05 localhost.localdomain NetworkManager[1101]: <info> [1566425765.4704] device (virbr0): state change: ip-config -> ip-check (reason 'non> Aug 21 18:16:05 localhost.localdomain NetworkManager[1101]: <info> [1566425765.4830] device (virbr0-nic): state change: disconnected -> prepare (reaso> Aug 21 18:16:05 localhost.localdomain NetworkManager[1101]: <info> [1566425765.4840] device (virbr0-nic): state change: prepare -> unmanaged (reason '> Aug 21 18:16:05 localhost.localdomain NetworkManager[1101]: <info> [1566425765.4849] device (virbr0-nic): released from master device virbr0 Aug 21 18:16:05 localhost.localdomain NetworkManager[1101]: <info> [1566425765.4857] device (virbr0): state change: ip-check -> secondaries (reason 'n> Aug 21 18:16:05 localhost.localdomain NetworkManager[1101]: <info> [1566425765.4970] device (virbr0): state change: secondaries -> activated (reason '> Aug 21 18:16:05 localhost.localdomain NetworkManager[1101]: <info> [1566425765.4979] manager: NetworkManager state is now CONNECTED_LOCAL Aug 21 18:16:05 localhost.localdomain NetworkManager[1101]: <info> [1566425765.5031] device (virbr0): Activation: successful, device activated. Aug 21 18:16:10 localhost.localdomain NetworkManager[1101]: <info> [1566425770.8772] manager: startup complete Aug 21 18:16:27 localhost.localdomain NetworkManager[1101]: <info> [1566425787.7609] agent-manager: req[0x556edf1b6360, :1.277/org.kde.plasma.networkm> [root@localhost ~]# nmcli device modify wlp3s0 wifi.mac-address-randomization never Error: Reading applied connection from device 'wlp3s0' (/org/freedesktop/NetworkManager/Devices/3) failed: Device is not activated
After getting more advice and trying a couple of things, this work around works for me, NetworkManager/conf.d/iwl.conf With contents, [device] match-device=driver:iwlwifi wifi.scan-rand-mac-address=no
(In reply to Nigel Sollars from comment #9) > After getting more advice and trying a couple of things, this work around > works for me, > > NetworkManager/conf.d/iwl.conf > > With contents, > > [device] > match-device=driver:iwlwifi > wifi.scan-rand-mac-address=no hello Nigel, thanks for the update. so this can be reconducted to known problems with wireless scans. Not 100% sure why the problem went in in the transition from f29 to f20, but I suspect the issue has something to do with latest enablement of CONFIG_MESH _ at least it proved to be a problem at least with broadcom 'wl' driver as per https://bugzilla.redhat.com/show_bug.cgi?id=1695696#c12 https://bugzilla.redhat.com/show_bug.cgi?id=1703745#c64 In case you want to try, I keep a version of wpa_supplicant where CONFIG_MESH is commented in the build config: https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/ and then report the testing results that to the iwlwifi maintainer.
I can confirm that the workaround that #9 proposes works: I have a T430s that I just swapped an Intel Centrino Ultimate-N 6300 card in on, the last that the t430s supports. previous card was an Intel Centrino Wireless-N 2200, worked fine. After the swap I was getting lists but I could not connect to networks. After applying the workaround and restarting NetworkManager, I can connect to both 2.4Ghz and 5Ghz networks.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs. Fedora 30 has now been rebased to 5.5.7-100.fc30. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
I've experienced the same connection issue with a Intel Corporation Centrino Ultimate-N 6300 on a Lenovo T520 laptop, after upgrading from F29 to F34. Running `sudo dnf install iwl6000-firmware` and then applying workaround in comment #9 made everything work perfectly again. Thanks a lot Nigel and Davide for your work; it saved me a few bucks and some time in not buying a Wifi dongle.
I'm facing the same issue, and none of the workarounds here worked.. I'm using: Thinkpad x230 Intel Centrino Ultimate-N 6300 Fedora 33 Network manager version: 1.26.8-1.fc33
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days