Bug 1655535 - Since F29 upgrade, Wi-Fi fails to connect: WARNING: CPU: 0 PID: 1111 at net/mac80211/wpa.c:443 ieee80211_crypto_ccmp_encrypt+0xa6/0x230 [mac80211]
Summary: Since F29 upgrade, Wi-Fi fails to connect: WARNING: CPU: 0 PID: 1111 at net/m...
Keywords:
Status: CLOSED DUPLICATE of bug 1582407
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-03 11:50 UTC by Russell Odom
Modified: 2019-07-29 14:42 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-28 11:11:32 UTC
Type: Bug


Attachments (Terms of Use)

Description Russell Odom 2018-12-03 11:50:52 UTC
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

Comment 1 Justin M. Forbes 2019-01-29 16:13:54 UTC
*********** 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.

Comment 2 Russell Odom 2019-02-01 19:18:27 UTC
Confirmed still present on 4.20.5-200.fc29.x86_64.

Comment 3 Laura Abbott 2019-04-09 20:45:08 UTC
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.

Comment 4 Russell Odom 2019-04-12 19:01:12 UTC
Confirmed still present on 5.0.6-200.fc29.x86_64.

Comment 5 Russell Odom 2019-07-25 18:07:49 UTC
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.

Comment 6 Jeremy Cline 2019-07-26 19:50:49 UTC
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?

Comment 7 dmanlfc 2019-07-27 01:08:59 UTC
Same problem Fedora 30 with Kernel 5.1.19-300.fc30.x86_64

Dan

Comment 8 Russell Odom 2019-07-28 11:11:32 UTC
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 ***

Comment 9 dmanlfc 2019-07-29 05:08:36 UTC
Looks like I have a different problem as that workaround doesn't solve my issue at all.
Should I open a seperate ticket?

Dan

Comment 10 Jeremy Cline 2019-07-29 14:42:25 UTC
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!


Note You need to log in before you can comment on or make changes to this bug.