Re: Aireos - Win10 20H2 cannot connect to WLAN - invalid MIC - Page 2

j.a.m.e.s · ‎05-18-2022

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.

j.a.m.e.s · ‎05-19-2022

I tried a few parameters outside business hours today:

Fast Transition: Adaptive -> Disabled
PMF (Management Protected Frames): Optional -> Disabled
Authentication Key Management: SHA1 and SHA2 -> Firstly just SHA2 then just SHA1
EAPOL Key Timeout: 1000ms to 3000ms

Disabling SHA1 impacted my existing clients, so I need to leave this on. Nothing seemed to help.

Would it be worth me putting an AP into sniffer mode and taking a capture?

MHM Cisco World · ‎05-19-2022

Request timeout and retires what I mean to change not eapol key timeout.

The ap/wlc send request to client if not receive reply the ap/wlc declared this client is unauth.

Will need to give client sometime to relpy.

JPavonM · ‎05-19-2022

Why you didn't test PMF optional with AKM's SHA1+SHA256 enalbed at the same time?

As you have tested, disabling SHA1 and only giving the option to use SHA256 is a bad idea, that's why my advice was to enable them both, plus PMF as optional, sorry if it wasn't clear enough.

j.a.m.e.s · ‎05-20-2022

> Why you didn't test PMF optional with AKM's SHA1+SHA256 enalbed at the same time?

The reason is that we have SHA1 and SHA2 already enabled while the M2 message is invalid.

In the end, I've asked our Desktop department to rebuild the laptops, so we will see if this helps next week.

The only avenue I haven't explored is Symantec Endpoint Protection as I'm informed that this is somehow involved in filtering the WLAN connection.

I will update this thread later next week.

MHM Cisco World · ‎05-20-2022

just to remember you do you try change request timeout and retries ? if no try it next week.

j.a.m.e.s · ‎05-24-2022

@MHM Cisco World wrote:
just to remember you do you try change request timeout and retries ? if no try it next week.

I have just checked, but we are well above the defaults:

Request Timeout: 30
Max Retries: 2

j.a.m.e.s · ‎05-24-2022

In the end, I finally fixed this by disabling SHA2 under "Authetication Key Management". I know had tested this earlier, but other issues ongoing at the time prevented me seeing the result.

The final settings which worked are:

I've no idea why certain clients didn't like having both enabled, but thank you to all for guiding me through this.

Many thanks.