Description of problem: Since upgrading my laptop from F27 to F29, it cannot connect to my wireless network. There is a kernel error (see below) whenever it tries. It can successfully scan and see the networks in the area, and attempt to connect. I have tried a completely separate network (tethered to my phone) with the same result. I have verified the network password is correct, and it appears that authentication is succeeding before the connection fails. What is confusing me is that if I reboot back into the F27 kernels which are still installed, the error still occurs - but it was working before the upgrade. Version-Release number of selected component (if applicable): kernel-4.18.18-100.fc27.x86_64 kernel-4.18.19-100.fc27.x86_64 kernel-4.19.5-300.fc29.x86_64 linux-firmware-20181008-88.gitc6b6265d.fc29.noarch <- same version as on F27 wpa_supplicant-2.6-17.fc29.x86_64 <- was wpa_supplicant-1:2.6-14.fc27.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Upgrade from F27 to F29 2. Try to connect to wireless network which worked previously Actual results: Wi-Fi fails to connect. Expected results: Wi-Fi connects. Additional info: [ 53.886726] wlp7s0: authenticate with 04:bf:6d:61:a4:99 [ 53.904546] wlp7s0: send auth to 04:bf:6d:61:a4:99 (try 1/3) [ 53.906820] wlp7s0: authenticated [ 53.907784] wlp7s0: associate with 04:bf:6d:61:a4:99 (try 1/3) [ 53.911461] wlp7s0: RX AssocResp from 04:bf:6d:61:a4:99 (capab=0x411 status=0 aid=1) [ 53.915777] rtl8192se: switch case 0x5e not processed [ 53.915802] wlp7s0: associated [ 53.972187] IPv6: ADDRCONF(NETDEV_CHANGE): wlp7s0: link becomes ready [ 53.972875] wlp7s0: deauthenticating from 04:bf:6d:61:a4:99 by local choice (Reason: 1=UNSPECIFIED) [ 53.973093] WARNING: CPU: 0 PID: 1111 at net/mac80211/wpa.c:443 ieee80211_crypto_ccmp_encrypt+0xa6/0x230 [mac80211] [ 53.973095] Modules linked in: ccm iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables sunrpc uvcvideo intel_powerclamp videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 coretemp videobuf2_common kvm_intel videodev kvm media snd_hda_codec_hdmi irqbypass intel_cstate arc4 intel_uncore snd_hda_codec_realtek rtl8192se gpio_ich snd_hda_codec_generic snd_hda_intel snd_hda_codec rtl_pci snd_hda_core rtlwifi snd_hwdep snd_seq wmi_bmof iTCO_wdt iTCO_vendor_support sparse_keymap mac80211 cfg80211 snd_seq_device joydev snd_pcm lpc_ich rfkill intel_ips snd_timer snd soundcore wmi mei_me mei i2c_i801 pcc_cpufreq acpi_cpufreq dm_crypt i915 i2c_algo_bit drm_kms_helper [ 53.973159] crc32c_intel drm serio_raw ums_realtek uas usb_storage atl1c video [ 53.973172] CPU: 0 PID: 1111 Comm: wpa_supplicant Not tainted 4.19.5-300.fc29.x86_64 #1 [ 53.973173] Hardware name: MEDION E7214 /E7214 , BIOS 4.6.3 06/25/2010 [ 53.973193] RIP: 0010:ieee80211_crypto_ccmp_encrypt+0xa6/0x230 [mac80211] [ 53.973196] Code: 93 84 00 00 00 4c 63 f8 8b 83 80 00 00 00 44 29 f8 89 04 24 85 d2 75 3c 31 c9 8b 83 cc 00 00 00 2b 83 c8 00 00 00 39 c8 7d 2a <0f> 0b b8 01 00 00 00 48 8b 4c 24 40 65 48 33 0c 25 28 00 00 00 0f [ 53.973197] RSP: 0018:ffffb0f98126b858 EFLAGS: 00010293 [ 53.973199] RAX: 0000000000000006 RBX: ffff8a472e8ed100 RCX: 0000000000000008 [ 53.973200] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000040c0 [ 53.973201] RBP: ffff8a4713cb2fe0 R08: ffffffffc0943120 R09: 000000000000000c [ 53.973203] R10: ffffffffc0943120 R11: ffff8a472e8ed130 R12: 000000000000001a [ 53.973204] R13: ffffb0f98126b948 R14: ffffb0f98126b950 R15: 0000000000000018 [ 53.973206] FS: 00007fb42b37f180(0000) GS:ffff8a4734000000(0000) knlGS:0000000000000000 [ 53.973207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 53.973208] CR2: 000055daada409d8 CR3: 0000000094d14000 CR4: 00000000000006f0 [ 53.973210] Call Trace: [ 53.973234] ? rate_control_get_rate+0xcd/0x140 [mac80211] [ 53.973255] invoke_tx_handlers_late+0x60e/0x830 [mac80211] [ 53.973280] ieee80211_tx+0xeb/0x140 [mac80211] [ 53.973306] __ieee80211_tx_skb_tid_band+0x5b/0x70 [mac80211] [ 53.973332] ieee80211_set_disassoc+0x3f8/0x580 [mac80211] [ 53.973359] ieee80211_mgd_deauth.cold.51+0x47/0x1b5 [mac80211] [ 53.973416] cfg80211_mlme_deauth+0xb3/0x1d0 [cfg80211] [ 53.973442] nl80211_deauthenticate+0x12d/0x170 [cfg80211] [ 53.973451] genl_family_rcv_msg+0x1ca/0x3a0 [ 53.973457] ? skb_queue_tail+0x1b/0x50 [ 53.973459] ? __netlink_sendskb+0x51/0x70 [ 53.973463] genl_rcv_msg+0x47/0x8c [ 53.973468] ? __kmalloc_node_track_caller+0x1df/0x2a0 [ 53.973470] ? genl_family_rcv_msg+0x3a0/0x3a0 [ 53.973473] netlink_rcv_skb+0x4c/0x120 [ 53.973476] genl_rcv+0x24/0x40 [ 53.973479] netlink_unicast+0x19e/0x260 [ 53.973482] netlink_sendmsg+0x1ff/0x3c0 [ 53.973488] sock_sendmsg+0x36/0x40 [ 53.973491] ___sys_sendmsg+0x295/0x2f0 [ 53.973495] ? sock_sendmsg+0x36/0x40 [ 53.973498] ? __sys_sendto+0xee/0x160 [ 53.973501] __sys_sendmsg+0x57/0xa0 [ 53.973508] do_syscall_64+0x5b/0x160 [ 53.973513] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 53.973516] RIP: 0033:0x7fb42b87cb58 [ 53.973519] Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 c5 6b 0c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 [ 53.973520] RSP: 002b:00007ffc23d05058 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 53.973523] RAX: ffffffffffffffda RBX: 000055daada0f940 RCX: 00007fb42b87cb58 [ 53.973525] RDX: 0000000000000000 RSI: 00007ffc23d05090 RDI: 0000000000000006 [ 53.973526] RBP: 000055daada46c10 R08: 0000000000000000 R09: 00007fb42b93eec0 [ 53.973527] R10: 000055daada05010 R11: 0000000000000246 R12: 000055daada0f850 [ 53.973529] R13: 00007ffc23d05090 R14: 0000000000000000 R15: 000055daada0d678 [ 53.973532] ---[ end trace 86b19e16e760e670 ]--- [ 55.022917] wlp7s0: authenticate with 04:bf:6d:61:a4:99 [ 55.033051] wlp7s0: send auth to 04:bf:6d:61:a4:99 (try 1/3) [ 55.036462] wlp7s0: authenticated [ 55.037146] wlp7s0: associate with 04:bf:6d:61:a4:99 (try 1/3) [ 55.040464] wlp7s0: RX AssocResp from 04:bf:6d:61:a4:99 (capab=0x411 status=30 aid=1) [ 55.040470] wlp7s0: 04:bf:6d:61:a4:99 rejected association temporarily; comeback duration 196 TU (200 ms) [ 55.243207] wlp7s0: associate with 04:bf:6d:61:a4:99 (try 2/3) [ 55.246589] wlp7s0: RX AssocResp from 04:bf:6d:61:a4:99 (capab=0x411 status=30 aid=1) [ 55.246598] wlp7s0: 04:bf:6d:61:a4:99 rejected association temporarily; comeback duration 196 TU (200 ms) [ 55.330830] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready [ 55.451162] wlp7s0: associate with 04:bf:6d:61:a4:99 (try 3/3) [ 55.454579] wlp7s0: RX AssocResp from 04:bf:6d:61:a4:99 (capab=0x411 status=30 aid=1) [ 55.454587] wlp7s0: 04:bf:6d:61:a4:99 rejected association temporarily; comeback duration 196 TU (200 ms) [ 55.660178] wlp7s0: association with 04:bf:6d:61:a4:99 timed out The "rtl8192se: switch case 0x5e not processed" error is a red herring - this has apparently always happened. Some interesting info from the journal, with some context around the above kernel messages (the last two "wpa_supplicant" lines look most relevant to me): Dec 03 11:30:38 host.example.com kernel: wlp7s0: associated Dec 03 11:30:38 host.example.com wpa_supplicant[1084]: wlp7s0: Associated with 04:bf:6d:61:a4:99 Dec 03 11:30:38 host.example.com wpa_supplicant[1084]: wlp7s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Dec 03 11:30:38 host.example.com NetworkManager[1022]: <info> [1543836638.0318] device (wlp7s0): supplicant interface state: authenticating -> associating Dec 03 11:30:38 host.example.com NetworkManager[1022]: <info> [1543836638.0341] device (wlp7s0): supplicant interface state: associating -> associated Dec 03 11:30:38 host.example.com NetworkManager[1022]: <info> [1543836638.0463] device (wlp7s0): supplicant interface state: associated -> 4-way handshake Dec 03 11:30:38 host.example.com wpa_supplicant[1084]: wlp7s0: WPA: Key negotiation completed with 04:bf:6d:61:a4:99 [PTK=CCMP GTK=CCMP] Dec 03 11:30:38 host.example.com kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp7s0: link becomes ready Dec 03 11:30:38 host.example.com wpa_supplicant[1084]: wlp7s0: CTRL-EVENT-CONNECTED - Connection to 04:bf:6d:61:a4:99 completed [id=0 id_str=] Dec 03 11:30:38 host.example.com wpa_supplicant[1084]: bgscan simple: Failed to enable signal strength monitoring Dec 03 11:30:38 host.example.com wpa_supplicant[1084]: wlp7s0: WPA: Failed to configure IGTK to the driver Dec 03 11:30:38 host.example.com kernel: wlp7s0: deauthenticating from 04:bf:6d:61:a4:99 by local choice (Reason: 1=UNSPECIFIED) $ sudo lspci -v -s 07:00.0 07:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller Flags: bus master, fast devsel, latency 0, IRQ 16 I/O ports at c000 [size=256] Memory at fba00000 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Legacy Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00 Kernel driver in use: rtl8192se Kernel modules: rtl8192se
*********** 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 29 kernel bugs. Fedora 29 has now been rebased to 4.20.5-200.fc29. 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 experience different issues, please open a new bug report for those.
Confirmed still present on 4.20.5-200.fc29.x86_64.
We apologize for the inconvenience. There is 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 29 kernel bugs. Fedora XX has now been rebased to 5.0.6 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 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
Confirmed still present on 5.0.6-200.fc29.x86_64.
Still present on 5.1.18-200.fc29.x86_64. Is there any information I can provide to get this moving? I'm stuck using this laptop on a wired network at the moment.
Hi Russell, This sounds super similar to https://bugzilla.redhat.com/show_bug.cgi?id=1586211. The kernel warning is happening when it's already trying to deauthenticate from the network. Can you walk through the steps described in the above bug?
Same problem Fedora 30 with Kernel 5.1.19-300.fc30.x86_64 Dan
Thanks Jeremy, that's cured it. I did: nmcli connection show nmcli connection modify [my_wifi_connection] wifi-sec.pmf disable ...then enabled the wifi (which I'd previously turned off). Immediate successful connection. *** This bug has been marked as a duplicate of bug 1582407 ***
Looks like I have a different problem as that workaround doesn't solve my issue at all. Should I open a seperate ticket? Dan
Hi Dan, Yes, please open a new bug and include detailed reproducer steps and kernel logs after you reproduce it ("journalctl --no-hostname -k > dmesg.txt"). Thanks!