Bug 197331 - iwlwifi: 7265: ASSERT 1007 when using AES-CCM and connecting with Mikrotik/RouterOS
Summary: iwlwifi: 7265: ASSERT 1007 when using AES-CCM and connecting with Mikrotik/Ro...
Status: CLOSED DUPLICATE of bug 172431
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: DO NOT USE - assign "network-wireless-intel" component instead
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-20 09:40 UTC by Andrzej Wes
Modified: 2017-10-23 06:28 UTC (History)
0 users

See Also:
Kernel Version: 4.13.7
Subsystem:
Regression: No
Bisected commit-id:


Attachments
iw scans when for TKIP and AES-CCM (4.28 KB, text/plain)
2017-10-20 09:40 UTC, Andrzej Wes
Details

Description Andrzej Wes 2017-10-20 09:40:42 UTC
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
Comment 1 Andrzej Wes 2017-10-20 10:44:21 UTC
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
Comment 2 Emmanuel Grumbach 2017-10-20 11:27:54 UTC
please check with sw_crypto=1 as a module parameter to iwlwifi.

Thanks.
Comment 3 Andrzej Wes 2017-10-20 11:53:15 UTC
"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!
Comment 4 Emmanuel Grumbach 2017-10-20 11:58:07 UTC
(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!
Comment 5 Andrzej Wes 2017-10-21 08:58:36 UTC
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.
Comment 6 Emmanuel Grumbach 2017-10-23 06:28:00 UTC
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 ***

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