cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10076
Views
20
Helpful
11
Replies

Intel AX200 unable to connect using 802.1X + SHA256

JPavonM
VIP
VIP

Hi community,

I'm suffering lack of connectivity when configuring WPA/WPA2 or WPA2/WPA3 WLAN profile with PMF optional or enabled, plus 802.1X-SHA1 plus 802.1X-SHA256 simultaneously.

Packet captures shows EAPOL failing on sending 4-way handshake M3 packet from client to AP.

However, with that same config, Intel AC8265 chipsets are sucessfully connecting but not Intel AC3165's. Different mobile devices are able to connect as well: iPad, iPhone 7, Xiaomi Mi8, Samsung S9.

Interesting enough, no Intel chipset I've tested is able to connect using only SHA256 (Intel 3165, 8265 and AX200).

The issue is reproducible with Cisco's latest code because in the previous ones there were many bugs affecting the use of SHA256. This is also reproducible with all of them AP models listed before


Conditions:

Cisco WLAN Infrastructure: Catalyst 9800 running IOS-XE 17.3.1 and different AP Models (AP3700, AP3800, AP4800, C9120, C9130). It also happen on Cisco AireOS 8.10.130 (same as before, previous versions has some bugs when using SHA256).


Laptop: Windows 10 version 2004 (OS Build 19041.264)

wNIC: Intel AX200

Driver: Intel PROSet Wireless 21.110 (also tested with version 21.90)


This is the output on the failure in the controller debug that shows MIC validation failed:

2020/08/18 09:41:03.306370 {wncd_x_R0-0}{1}: [client-orch-sm] [25343]: (info): MAC: aabb.ccdd.eeff Deleting the client, reason: 91, CO_CLIENT_DELETE_REASON_KEY_MGMT_MIC_VALIDATION, Client state S_CO_L2_AUTH_IN_PROGRESS
2020/08/18 09:41:03.306374 {wncd_x_R0-0}{1}: [tdllib] [25343]: (debug): ewlc/client/client_orch/_gen_lib_tpp_x86_64_cge7/client_orch_stats.c:2184:5: ewlc_client_orch_libctxt->client_orch_stats_rec->field_st_client_orch_stats_ptr->client_del_reason.co_client_delete_reason_key_mgmt_mic_validation_ctr++: db=WNCD_DB, tid=0, obj_ptr=0x808098fe48, write_ptr=0x808098ffc0, size=4
2020/08/18 09:41:03.306378 {wncd_x_R0-0}{1}: [client-orch-sm] [25343]: (debug): Search wlan client stats record exists for given wlan id: 39
2020/08/18 09:41:03.306379 {wncd_x_R0-0}{1}: [tdllib] [25343]: (debug): ewlc/client/client_orch/_gen_lib_tpp_x86_64_cge7/client_orch_wlan_client_stats.c:2942:5: rec->field_wlan_client_stats_ptr->client_del_reason.co_client_delete_reason_key_mgmt_mic_validation_ctr++: db=WNCD_DB, tid=0, obj_ptr=0x8080e84718, write_ptr=0x8080e84890, size=4
2020/08/18 09:41:03.306383 {wncd_x_R0-0}{1}: [client-orch-sm] [25343]: (debug): MAC: aabb.ccdd.eeff local ipv6 deletemmif_role_status: 0, Success, client role: Unassoc
2020/08/18 09:41:03.306396 {wncd_x_R0-0}{1}: [client-ipv6-client] [25343]: (debug): MAC: aabb.ccdd.eeff Failed to find client in mgid table
2020/08/18 09:41:03.306407 {wncd_x_R0-0}{1}: [client-orch-sm] [25343]: (debug): transition buffer: written 96 position 5
2020/08/18 09:41:03.306408 {wncd_x_R0-0}{1}: [client-orch-sm] [25343]: (note): MAC: aabb.ccdd.eeff Client delete initiated. Reason: CO_CLIENT_DELETE_REASON_KEY_MGMT_MIC_VALIDATION, fsm-state transition 00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|01|07|13|1a|23|

Is there any one who has sucessfully configured 802.1X with SHA256 and managed to connect an Intel AX200? And what about 802.1X with SHA1+SHA256?


NOTE: I have a discussion open on Intel Community if you want to add additional data:

Intel-AX200-fails-to-connect-using-SHA256


Regards

1 Accepted Solution

Accepted Solutions

JPavonM
VIP
VIP

Further investigations by Intel has led to a Windows 10 issue when using that AKM.

View solution in original post

11 Replies 11

patoberli
VIP Alumni
VIP Alumni
Was just hit with this issue. I had for testing enabled 802.1X-SHA2 in the SSID security properties (or was it enabled by default after 8.10.130.0?) and no client was able to connect. Rarely my Android phone, but no other client. After disabling this option (while leaving 802.1x-SHA1 and CCKM enabled) they were able to connect again. I have WPA3 disabled, PMF Optional und FT disabled, if that plays a role.

I was hit by the issue as well after upgrading from 8.8.130.0 to 8.10.130.0. I have a TAC case open regarding other bugs in 8.10.130.0 (wrong tansmit power, defective local profiling, wrong client capabilities, WPA3 Enterprise missing in ME GUI) and was switching between releases. This time I had PMF enabled and set to optional what somehow caused 802.1X-SHA2 and 802.1X to be enabled on the SSID after the upgrade. I did this a few times for testing and the other times with PMF disabled I had no issues to connect to the SSID after the upgrade. Intel card is 9560 with 21.110.1.1 driver, AP's are 2802i.

 

I have seen in your thread in the Intel forum that Cisco engineering is working on it with Intel, so hopefully we will get a stable 8.10.x release soon and fixed Intel drivers.

JPavonM
VIP
VIP

Further investigations by Intel has led to a Windows 10 issue when using that AKM.

merlin76
Level 1
Level 1

I have found a post on Intel wireless forum regarding the Win10 2004 issue and current workaround is to disable PMF.

 

https://community.intel.com/t5/Wireless/WPA2-Enterprise-unable-to-connect-in-Windows-10-version-2004/m-p/1187887#M29624

 

Does anyone know if Microsoft is working on a fix?

I think with any issue like what we have seen in the past, it will be fixed when it’s a priority during their release cycle like any other organization. We seen these issue with 802.11n and when other features were introduced. You might be better off opening up a case and getting follow up on the fix.
-Scott
*** Please rate helpful posts ***

I think we will have to wait for Win 10 21H1. Accoding to the following article Win 10 2004 only supports WPA3 Personal: https://thewincentral.com/windows-10-21h1-iron-will-bring-support-for-wi-fi-wpa3-enterprise-192-bit-encryption/

 

Other issue is that in 8.10.130.0 changelog for ME, Cisco states support for WPA3 without any details. But 5520 changlog states: Open, WPA3-SAE/OWE ( WPA3 Supported Clients), WPA2+WPA3 ( Mixed Mode) PSK (WPA2-AES), 802.1X (WPA2-AES)(EAP-PEAP). So it seems WPA3 Enterprise currently only is officially supported on 9800 altough you can configure it on CLI on the AireOS controllers.

I have recently tested windiows10 (ax200) with WPA3 Enterprise. I used 9800 WLC and will test with AireOS to see any issues

https://mrncciew.com/2020/08/17/wpa3-enterprise/ 

 

HTH

Rasika

 

JPavonM
VIP
VIP

But this issue I've seen with Intel AX200 and AC3165 is not in regards of WPA3 but different Hash algorythms when using WPA2.

Enabling SHA1 + SHA256 under AKM, those Intel chiset cannot associatte the WLAN, BUT Intel AC8265 can, and use SHA256 as per my packet captures.

I doubt this is a Windows issue as Intel support told me, if that was the case, even AC8265 would fail to join.

Yes, got you. I don't understand why it works for one chipset if it's an OS limitation, perhaps it is a bug in the driver that makes it work somehow.

 

I had this issue as well with 802.1X-SHA2 and 802.1X enabled and PMF set to optional, WPA3 was not enabled. My thought was, that if Microsoft updated Win10 2004 to add official support for WPA3 Personal and will bring support for WPA3 Enterprise later next year, SHA256 + PMF should work fine until then as it is mandatory.

 

The issue with SHA256 and PMF seems only to be present in 2004, earlier releases seem to be fine. Currently, I'm waiting for TAC for a new 8.10 release with my reported bugs fixed, until then I'll stay on 8.8 and enjoy having no issues.

merlin76
Level 1
Level 1

@Rasika Nayanajith 

Sorry, did not see your posting. Thanks for posting the article, awesome. So it seems Win10 2004 is ready for all flavours and the WinCentral article is just false news.

Some_Guy
Level 1
Level 1

I have also experienced the same problem with Intel AX201, Intel AC7260 and Qualcomm QCA61x4A. The problem exists in Windows 10 feature version 2004, 20H2 and 21H1. Earlier versions of Windows 10 (<=1909) work fine.

Microsoft finally fixed it in KB5003690. Effectively this means that to get the fix, Windows 10 clients running feature version 2004 or later need to have the "July 2021 cumulative quality update" or later. The fix has solved the problem for me.

See the Microsoft release notes here: https://support.microsoft.com/en-gb/topic/june-21-2021-kb5003690-os-builds-19041-1081-19042-1081-and-19043-1081-preview-expired-11a7581f-2a01-47d5-ba12-431709ee2248

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.

 

Review Cisco Networking products for a $25 gift card