Created attachment 260301 [details] iw scans when for TKIP and AES-CCM Hello, I'm using Arch linux with kernel 4.13.7. Network controller: Intel Corporation Wireless 7265 (rev 61) iwlwifi restarts repeatedly when connected to a Mikrotik router (RouterOS 6.40.4) and using AES-CCM as encryption. When encryption is set to TKIP - it works fine. dmesg log of a restart: [08:05:43 2017] wlo1: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-22) [08:05:47 2017] wlo1: authenticate with 6c:3b:6b:f6:1c:f9 [08:05:47 2017] wlo1: send auth to 6c:3b:6b:f6:1c:f9 (try 1/3) [08:05:47 2017] wlo1: authenticated [08:05:47 2017] wlo1: associate with 6c:3b:6b:f6:1c:f9 (try 1/3) [08:05:47 2017] wlo1: RX AssocResp from 6c:3b:6b:f6:1c:f9 (capab=0x431 status=0 aid=1) [08:05:47 2017] wlo1: associated [08:06:03 2017] iwlwifi 0000:08:00.0: Microcode SW error detected. Restarting 0x2000000. [08:06:03 2017] iwlwifi 0000:08:00.0: Start IWL Error Log Dump: [08:06:03 2017] iwlwifi 0000:08:00.0: Status: 0x00000200, count: 6 [08:06:03 2017] iwlwifi 0000:08:00.0: Loaded firmware version: 29.541020.0 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00001007 | ADVANCED_SYSASSERT [08:06:03 2017] iwlwifi 0000:08:00.0: 0x008006F0 | trm_hw_status0 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000000 | trm_hw_status1 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00043D58 | branchlink2 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x0004B016 | interruptlink1 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000000 | interruptlink2 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00030400 | data1 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x0000040B | data2 [08:06:03 2017] iwlwifi 0000:08:00.0: 0xDEADBEEF | data3 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x27411302 | beacon time [08:06:03 2017] iwlwifi 0000:08:00.0: 0x04E59CD8 | tsf low [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000001 | tsf hi [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000000 | time gp1 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x0140950B | time gp2 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000001 | uCode revision type [08:06:03 2017] iwlwifi 0000:08:00.0: 0x0000001D | uCode version major [08:06:03 2017] iwlwifi 0000:08:00.0: 0x0008415C | uCode version minor [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000210 | hw version [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00C89200 | board version [08:06:03 2017] iwlwifi 0000:08:00.0: 0x0A34001C | hcmd [08:06:03 2017] iwlwifi 0000:08:00.0: 0x80022003 | isr0 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00800000 | isr1 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x0000000A | isr2 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x004178C5 | isr3 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000080 | isr4 [08:06:03 2017] iwlwifi 0000:08:00.0: 0x8726009D | last cmd Id [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000000 | wait_event [08:06:03 2017] iwlwifi 0000:08:00.0: 0x0000D3F1 | l2p_control [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00002020 | l2p_duration [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000003 | l2p_mhvalid [08:06:03 2017] iwlwifi 0000:08:00.0: 0x000000FE | l2p_addr_match [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00000005 | lmpm_pmg_sel [08:06:03 2017] iwlwifi 0000:08:00.0: 0x15061956 | timestamp [08:06:03 2017] iwlwifi 0000:08:00.0: 0x00008898 | flow_handler I've also attached "iw scan" results: - when AES-CCM is on and restarts occure - when TKIP and wifi is working fine Best regards, Andrzej
Important note: I've tested connection with a different router, and it worked fine while using AES-CCM. So it looks like it might be a specific issue when connecting with Mikrotik/RouterOS. "iw scan" for different AES-CCM network, that works (not-Mikrotik): BSS a0:f3:c1:17:8c:d9(on wlo1) last seen: 7498.263s [boottime] TSF: 898806947 usec (0d, 00:14:58) freq: 2412 beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime (0x0411) signal: -45.00 dBm last seen: 1210 ms ago Information elements from Probe Response frame: SSID: PiRouter Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 DS Parameter set: channel 1 ERP: Barker_Preamble_Mode Extended supported rates: 24.0 36.0 48.0 54.0 RSN: * Version: 1 * Group cipher: CCMP * Pairwise ciphers: CCMP * Authentication suites: IEEE 802.1X PSK IEEE 802.1X/SHA-256 PSK/SHA-256 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c) Extended capabilities: SSID List, 6 WMM: * Parameter version 1 * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec Best regards
please check with sw_crypto=1 as a module parameter to iwlwifi. Thanks.
"sw_crypto=1" worked around the problem. I've downloaded a fair amount of data and didn't experienced any wifi restart. It this a final solution for me or some driver/firmware fix will appear someday? Thanks!
(In reply to Andrzej Wes from comment #3) > "sw_crypto=1" worked around the problem. > I've downloaded a fair amount of data and didn't experienced any wifi > restart. > It this a final solution for me or some driver/firmware fix will appear > someday? TBH, I don't know. This assert is usually related to interference / radio problems. The fact that it is security related is interesting. I will try to get someone from the firmware team to look at this. They will surely need more data. We'll get back to you. > > Thanks!
Sorry for misleading you: after rebooting my machine, the problem of restarting iwlwifi still exists. I still have option "sw_crypto=1" active. After switching to TKIP encryption works fine, though.
Note that TKIP disables 11n and hence you have much less throughput which can have a major impact on the radio aspect (no 40MHz etc...). The fact that the bug reproduces with sw_crypto=1 as well confirms this. What can happen here is that your platform is generating a noise that disturbs the WiFi operation on the extension channel (the other 20MHz that composes the 40MHz) and that with TKIP, since you don't work on 40MHz but only on 20MHz, you can't hear that noise. You may try to disable 40MHz operation and go to 20MHz only and check what happens. I am closing this bug this we can't do anything more than that unfortunately. You can try to see what has been said in the other bugs of this kind (you'll see the number soon). Feel free to add comments after I close the bug, we'll still be notified. Thanks! *** This bug has been marked as a duplicate of bug 172431 ***