Aireos - Win10 20H2 cannot connect to WLAN - invalid MIC

[j.a.m.e.s]

Using the Intel AX201 and AireOS 8.10.162.11, our Desktop team are building a lot of laptops which can't connect to our WLAN. When doing a debug, I can see:

*Dot1x_NW_MsgTask_4: May 16 14:20:05.208: [PA] a4:42:3b:7x:xx:xx Entering Backend Auth Success state (id=232) for mobile a4:42:3b:7x:xx:xx
*Dot1x_NW_MsgTask_4: May 16 14:20:05.208: [PA] a4:42:3b:7x:xx:xx dot1x - moving mobile a4:42:3b:7x:xx:xx into Authenticated state
*dot1xSocketTask: May 16 14:20:05.224: [PA] a4:42:3b:7x:xx:xx validating eapol pkt: key version = 3
*Dot1x_NW_MsgTask_4: May 16 14:20:05.224: [PA] a4:42:3b:7x:xx:xx Received EAPOL-Key from mobile a4:42:3b:7x:xx:xx
*Dot1x_NW_MsgTask_4: May 16 14:20:05.224: [PA] a4:42:3b:7x:xx:xx Ignoring invalid EAPOL version (1) in EAPOL-key message from mobile a4:42:3b:7x:xx:xx
*Dot1x_NW_MsgTask_4: May 16 14:20:05.224: [PA] a4:42:3b:7x:xx:xx key Desc Version FT - 0

*Dot1x_NW_MsgTask_4: May 16 14:20:05.224: [PA] a4:42:3b:7x:xx:xx Encryption Policy: 4, PTK Key Length: 48
*Dot1x_NW_MsgTask_4: May 16 14:20:05.224: [PA] a4:42:3b:7x:xx:xx Successfully computed PTK from PMK!!!
*Dot1x_NW_MsgTask_4: May 16 14:20:05.224: [PA] a4:42:3b:7x:xx:xx Received EAPOL-key M2 with invalid MIC from mobile a4:42:3b:7x:xx:xx version 3
*osapiBsnTimer: May 16 14:20:06.218: [PA] a4:42:3b:7x:xx:xx 802.1x 'timeoutEvt' Timer expired for station a4:42:3b:7x:xx:xx and for message = M2
*Dot1x_NW_MsgTask_4: May 16 14:20:06.218: [PA] a4:42:3b:7x:xx:xx Retransmit 1 of EAPOL-Key M1 (length 121) for mobile a4:42:3b:7x:xx:xx
*dot1xSocketTask: May 16 14:20:06.219: [PA] a4:42:3b:7x:xx:xx validating eapol pkt: key version = 3
*Dot1x_NW_MsgTask_4: May 16 14:20:06.219: [PA] a4:42:3b:7x:xx:xx Received EAPOL-Key from mobile a4:42:3b:7x:xx:xx
*Dot1x_NW_MsgTask_4: May 16 14:20:06.219: [PA] a4:42:3b:7x:xx:xx Ignoring invalid EAPOL version (1) in EAPOL-key message from mobile a4:42:3b:7x:xx:xx
*Dot1x_NW_MsgTask_4: May 16 14:20:06.219: [PA] a4:42:3b:7x:xx:xx key Desc Version FT - 0

*Dot1x_NW_MsgTask_4: May 16 14:20:06.220: [PA] a4:42:3b:7x:xx:xx Received EAPOL-key in PTK_START state (message 2) from mobile a4:42:3b:7x:xx:xx
*Dot1x_NW_MsgTask_4: May 16 14:20:06.220: [PA] a4:42:3b:7x:xx:xx Encryption Policy: 4, PTK Key Length: 48
*Dot1x_NW_MsgTask_4: May 16 14:20:06.220: [PA] a4:42:3b:7x:xx:xx Successfully computed PTK from PMK!!!
*Dot1x_NW_MsgTask_4: May 16 14:20:06.220: [PA] a4:42:3b:7x:xx:xx Received EAPOL-key M2 with invalid MIC from mobile a4:42:3b:7x:xx:xx version 3
*osapiBsnTimer: May 16 14:20:07.226: [PA] a4:42:3b:7x:xx:xx 802.1x 'timeoutEvt' Timer expired for station a4:42:3b:7x:xx:xx and for message = M2
*Dot1x_NW_MsgTask_4: May 16 14:20:07.226: [PA] a4:42:3b:7x:xx:xx Retransmit 2 of EAPOL-Key M1 (length 121) for mobile a4:42:3b:7x:xx:xx
*dot1xSocketTask: May 16 14:20:07.228: [PA] a4:42:3b:7x:xx:xx validating eapol pkt: key version = 3
*Dot1x_NW_MsgTask_4: May 16 14:20:07.228: [PA] a4:42:3b:7x:xx:xx Received EAPOL-Key from mobile a4:42:3b:7x:xx:xx
*Dot1x_NW_MsgTask_4: May 16 14:20:07.228: [PA] a4:42:3b:7x:xx:xx Ignoring invalid EAPOL version (1) in EAPOL-key message from mobile a4:42:3b:7x:xx:xx
*Dot1x_NW_MsgTask_4: May 16 14:20:07.228: [PA] a4:42:3b:7x:xx:xx key Desc Version FT - 0

I've tried updating the Intel Drivers. The Desktop team are sure we're patched to the most recent cumulative update (May 2022). 

From looking at the above, can anyone tell if this is the Microsoft bug described in this post? 

Addresses an issue that causes Wi-Fi connections to fail because of an invalid Message Integrity Check (MIC) on a four-way handshake if Management Frame Protection (MFP) is enabled.

We have client MFP disabled on the WLAN, which surely means the bug shouldn't apply.

[marce1000]

 >...I've tried updating the Intel Drivers. The Desktop team are sure we're patched to the most recent cumulative update (May 2022). 

 - You should be more definitive on that , note also  that Windows updates are unrelated to updating Intel drivers (normally)

 M.

[j.a.m.e.s]

We are definitely using the latest Intel drivers and have the May 2022 MS update! 

[MHM Cisco World]

check the PSK is enter right, please find the log of Wrong secret from cisco it same as your log message.

[j.a.m.e.s]

Thank you for the suggestion, but we have no PSK on this WLAN. It uses EAP-TLS to send a machine certificate only. 

[MHM Cisco World]

are machine Certificate is sign from same CA trust point of WLC/Radius ?

[j.a.m.e.s]

No. The laptop certs are signed by one CA. The Radius (ISE) cert is signed by another CA. However, I don't think this is a problem as the client supplicant is configured to trust the RADIUS cert CA and ISE is configured to validate the laptop's CA. This arrangement is working for thousands of laptops.

[Leo Laohoo]

In CMD, please post the complete output to the command "netsh show wlan drivers".

[j.a.m.e.s]

c:\>netsh wlan show driver

Interface name: Wi-Fi

    Driver                    : Intel(R) Wi-Fi 6 AX201 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 15.03.2022
    Version                   : 22.130.0.5
    INF file                  : oem235.inf
    Type                      : Native Wi-Fi Driver
    Radio types supported     : 802.11b 802.11g 802.11n 802.11a 802.11ac 802.11ax
    FIPS 140-2 mode supported : Yes
    802.11w Management Frame Protection supported : Yes
    Hosted network supported  : No
    Authentication and cipher supported in infrastructure mode:
                                Open            None
                                Open            WEP-40bit
                                Open            WEP-104bit
                                Open            WEP
                                WPA-Enterprise  TKIP
                                WPA-Enterprise  CCMP
                                WPA-Personal    TKIP
                                WPA-Personal    CCMP
                                WPA2-Enterprise TKIP
                                WPA2-Enterprise CCMP
                                WPA2-Personal   TKIP
                                WPA2-Personal   CCMP
                                Open            Vendor defined
                                WPA3-Personal   CCMP
                                Vendor defined  Vendor defined
                                WPA3-Enterprise GCMP-256
                                OWE             CCMP
    IHV service present       : Yes
    IHV adapter OUI           : [00 00 00], type: [00]
    IHV extensibility DLL path: C:\WINDOWS\system32\IntelIHVRouter08.dll
    IHV UI extensibility ClSID: {00000000-0000-0000-0000-000000000000}
    IHV diagnostics CLSID     : {00000000-0000-0000-0000-000000000000}
    Wireless Display Supported: Yes (Graphics Driver: Yes, Wi-Fi Driver: Yes)

[Leo Laohoo]

Thanks for the output. 

Is that correct the WLC is on 8.10.162.11?  That is a Special Engineering release.  

[JPavonM]

As perfectly described in this excellent post from Kemparaj Praneeth, MIC generation in the client side for M2 takes some seeds from the client side, so this seems to be an issue on whatever part of the client side that takes account of that (Win10 or Intel driver).

Maybe changing hash from SHA1 to SHA256 in the WLAN config would do the trick to generate a different MIC.

Or maybe update Win10 to get the latest TCPIP library version as Win10 20H2 is not latest release.

[j.a.m.e.s]

Where do you set the hash from SHA1 to SHA256 ? I can see a "Security Profile" is set but I couldnt find where to change this.

[j.a.m.e.s]

If I change "Fast Transition" from Adaptive to Disabled, do you think this would change the hash type?

[JPavonM]

You can find it if you optionally enable 802.11w-PMF, and then under AKM you select SHA256 and SHA1.

For your Win10 version the issue with 802.11w-PMF from Win10 side is fixed so you should be able to join using PMF and SHA256.

And yes, I would give a try also disabling dot11r as Adaptive is only for Apple devices.

[MHM Cisco World]

I check the message 
there is retransmit message,
please can you increase the EAP timer
some client need more time to exchange the EAP message