Long-term dropouts with Intel AXxxx & BExxx chipsets

[Dezz]

For well over a year we've been experiencing dropout issues with the above chipsets in Dell Latitude laptops. This issue appears in many other threads in this forum, and appears to be specifically related to EAP-TLS / certificate authentication. 

The client drops their connection and the following is logged in the wlan report:

4042 2026-01-13T12:59:28
[‒]Capability change on {d2ec674e-2ff2-439b-ab15-7e2e2bdf8369} (0x47008000000000 Family: V4 Capability: None ChangeReason: SuspectArpProbeFailed)
11004 2026-01-13T13:00:46
[+]Wireless security stopped.

The issue happens with multiple users and sites running on Cisco WLC9800 & Cisco access points. We have had thorough investigation from our network team and Cisco TAC who say it's not a WLC/AP issue. On the Guest/WPA-PSK SSIDs the connections are stable.  

We have tried BIOS updates, driver updates for both WiFi/BT from a clean install. Changes to the WiFi settings for roaming aggressiveness, 801.2a/b/g & n/ac/ax wireless modes.

This is happening on multiple clients with Intel AXxxx & BExxx NICs. 

The clients do not see these issues when on WPA2/PSK WiFi, only EAP-TLS/device (cert auth). 

The issue has occurred on driver version 23.120.x-23.170.x,  24.04.x & 24.10.0 versions. Fast roaming (FT) has been enabled and disabled. 

Links to other articles with very similar issue and no solid resolution:

WiFi6 AX201 160MHz Capability Reset and WiFi Disconnection Issues - Intel Community

Re: Improve reliability of Intel AX200 WiFi connection / frequent disconnects - Intel Community

Intel Wifi AX (No Internet) Intermittent/ChangeReason: CapabilityReset - Intel Community

[TheExpertGuy]

Intel AX & BE adapters sometimes reset capabilities or fail to maintain a stable state during certificate-based roaming, which is why you see SuspectArpProbeFailed and Wireless security stopped in the WLAN reports. The fact that this occurs across multiple driver versions (23.120.x–24.10.x) and even after BIOS, clean OS installs, and roaming/aggressiveness adjustments indicates it’s likely a driver/firmware-level behavior triggered by EAP-TLS traffic patterns. 

Try these steps ->

1. Force 11ax / 802.11ac Compatibility Mode

Go to Device Manager > Intel Wi-Fi Adapter > Properties > Advanced. Set Wireless Mode to 802.11ac (disable ax temporarily). Some enterprise EAP-TLS flows are more stable in AC-only mode.

2. Disable Fast Roaming / FT & 802.11k/v

FT (Fast BSS Transition) can trigger capability resets on certain Intel NICs during 802.1X authentication. Disable FT, 802.11k, and 802.11v in both the NIC settings and on the controller if possible.

3. Adjust Roaming Aggressiveness / Power Settings

Set Roaming Aggressiveness to “Lowest” to reduce handoff attempts during certificate re-auth. Under Power Management > uncheck “Allow the computer to turn off this device to save power.”

4. make sure Intel PROSet Enterprise / Wireless Management Software Is Installed

5. Check Group Policy / Network Policy Certificate Validity

On Windows, run certutil -store MY and certutil -verify for your client cert.

6. Some threads note better stability with driver version 22.120.x for AX201 / AX200 series in enterprise 802.1X environments. Test one client with the older driver to see if it reduces disconnects (while noting security implications).

Unfortunately, this isn’t a WLC/AP misconfiguration, it’s very likely a driver or NIC firmware interaction with EAP-TLS. Some enterprise users have mitigated these issues by sticking with AC-only mode, disabling FT, and carefully selecting driver versions

[Dezz]

Many thanks for the comprehensive response, @TheExpertGuy. It certainly does feel like an issue around the EAP-TLS on the Intel cards. We deployed a number of USB dongles with Realtek chipsets and their issues went away, which reinforces it being an Intel-related or inter-operability issue. Unfortunately this isn't an viable solution with 1000+ users.

We've tried almost all of the available options above. My reason for posting here was to try and get some focus and traction from Intel regarding an issue which appears to sit with their hardware/driver software. Very similar issues with the Intel chipsets appear in other Dell, Lenovo, Cisco & Meraki forums with no definitive answers unfortunately. 

[CaNeBuRy23]

...the most effective mitigation has been to standardize on a known-stable Intel driver branch rather than the latest release. i suggest testing a rollback to an earlier Intel PROSet/Wireless driver version that predates the introduction of WPA3 and advanced roaming optimizations, as these changes have been observed to impact EAP-TLS authentication in some environments. In parallel, disabling the following advanced adapter features on affected systems has resolved or significantly reduced authentication failures:

1. Fast Roaming (802.11r)

2. MAC Randomization / Private Addressing

3. PMF (Protected Management Frames) where optional

4. WPA3 transition mode, if enabled

On the RADIUS side, ensuring certificate chains are delivered in full (including intermediates) and confirming TLS 1.2 is explicitly allowed rather than negotiated has also helped stabilize Intel client authentication.

[Dezz]

Thanks @CaNeBuRy23 

We have disabled those options on the WLC/APs and I'm advised that the other roaming settings are set within the driver itself and cannot be changed:

"These features are permanently enabled at the driver level for all Intel® AX and BE series wireless adapters. The Intel driver automatically exchanges the necessary frames with your Access Points (APs) to build an optimized map of the network for improved roaming performance.

Because these capabilities are considered essential for modern Wi-Fi efficiency, they cannot be disabled through the Windows user interface. The 802.11r, 802.11k, and 802.11v fast roaming features are automatically handled by the Windows operating system and the Intel wireless driver, provided that your network infrastructure (APs/routers) also supports and has these features enabled. At this time, there is no specific toggle or on/off switch available in the adapter’s configuration settings to disable/enable these modes."

As far as I'm aware the certificate chain and TLS are fine, plus, the Realtek adapters don't appear to have the issue. 

I could try and get hold of the earlier drivers to test, however, this isn't ideal and we do have update processes and auditing systems in-place to ensure that they are kept up-to-date. The correct answer surely is to resolve whatever is causing the issue within the driver software!

[Robbyde]

Hello,
Any luck with this? We're having exactly the same issue.

I think we started getting this issue post Jan windows update.

I've tried intel drivers 22 but it hasn't helped.
Just about to raise a tac case with Cisco.

What version of the 9800 are you running out of interest?

[Dezz]

Hi @Robbyde 

We're on 

This has been an issue for use for 18 months+ now I believe.

As we've exhausted all suggestions the current thinking is to push out WPA2-PSK authentication as we believe this is almost certainly an issue in the Intel driver with EAP-TLS and something we cannot fix ourselves. Another option (for our remote offices) is to disable one of the pair of APs so that roaming doesn't occur, which appears to be part of the issue.

It seems ludicrous that we can't reap the benefits of features like FT, PMF, PMK and pre-auth etc. over this issue and backward steps are necessary...

We've also had a case open with Cisco for over a month without much success, please keep us updated with how you get on!

[Robbyde]

Hello,

All cisco TAC have suggested is to turn off protected frames.  

We're on version 17.15.3 of the controller, mostly running 9120 APs.

we have seen this error on both 802.1x ssid's and psk networks:

[‒]Capability change on {91eae6dd-bb8e-4f53-b0f6-f748baaf7868} (0x47008000000000 Family: V4 Capability: None ChangeReason: SuspectArpProbeFailed)

One user seems ok now which is odd as I'm not sure we've done anything other than update his machine.

[Dezz]

apologies, version is Cisco IOS Software, C9800-CL Software (C9800-CL-K9_IOSXE), Version 17.12.4

[harfri]

Hi, 
Thanks for the write up, we're seeing the same issues across our systems. For us the only reports are coming from the BE201 card, not any earlier AX NICs. 

Same issue on locations with WPA3 features and not. 

No change with the latest Intel driver 24.10.0 

We're currently on Version 17.15.4b 

We manage about 2500 clients with the Intel BE201, so far the issue does not seem so widespread but it could be due to most of the clients are mainly on LAN as well as the dropouts are generally very short for most people. 

[Dezz]

@Robbyde, have you made any further progress on this? 

We had our network team disable 6GHz and PMF/FT and we still see the issue, which appears to be when the client roams. The EAP timeouts and handshake errors no longer appear in the WLC/AP logs, however the client still drops during a roaming event. 

In the netsh wlan show wlanreport output we see the same events at the time of the drop:

It would be helpful to get traction from an Intel representative on this matter, is there any way to do this other than via this forum?

[Dezz]

Thanks for the input, @harfri We are using AIR-AP3802I-E-K9 APs version 17.12.4.158. Which APs do you have and  do you know if the version you have is an upgrade on ours? Apologies, we don't have access to the network ourselves unfortunately. 

Thanks.

[harfri]

Mainly: 

Aironet 2802I-E 

Catalyst 9120AXI-E

CW9176I-CFG

Our Cisco version is newer, but not much better it appears. 

[harfri]

Hi team, 

From our testing today it seemed like disabling Opportunistic Key Caching (OKC) proved to have the biggest improvement.  

However, even though systematically going through settings this "ghost" appears to work again with it re-enabled, so we're unsure if it actually made any difference. 

Feel free to test this setting on your end too and see if you notice an improvement. 

On another note, HP systems does not appear to have this issue at all, even with the same generation, NIC and driver versions. 

[Robbyde]

Unfortunately it's already off for us.

Cisco thought it might have been protected frames but that's also optional for us.

[Dezz]

Thanks @harfri. Interesting you mention HP, we have seen the same issue on Lenovo's which do have the same Intel cards (AXxxx) and drivers. 

Would it be possible for you to post the output of PowerShell Get-NetAdapterAdvancedProperty W*i | ft DisplayName, DisplayValue, ValidDisplayValues from a working/stable HP please?

We get the issue on default settings and a variety of tweaks to the roaming aggressiveness, transmit power, wireless modes etc. 

We've yet to try turning off OKC but it doesn't look like it helps, much like everything else on the AP/WLC side

[harfri]

Sorry for the late reply, looks to be the exact same settings as our Lenovos. 



We have got some 

[harfri]

We have an ongoing L2 case with Lenovo, we got sent a Intel WRT2 logging tool, hopefully it catches something we haven't. 

[Dezz]

Thanks @harfri  those NIC settings look to be default which we've tried and others. I'd be interested to hear more about that tool and how you get on. 

We had no drops in the remote office yesterday and then today a few within the first hour, which all appear to happen when/after the client roamed. I'm still waiting for Cisco to respond to the log traces but won't hold my breath. 

Intel released a new driver on 10/2 (24.20.0) which mentions an option to disable roaming based on AP load rather than signal strength - I don't think it's directly related to this but we're going to test it. 

[Dezz]

New driver, no difference, unfortunately. Client roams from 1 AP to another and drops out with the same sequence of events in the wlan report file. 

[Random123]

Hi,

Here another one affected by this issue. Have anyone get any official information?

Thanks.

Kind regards.