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

[harfri]

Short update from our end is that tickets have been escalated to Lenovo and Microsoft (Surface) 

The tech we spoke with from Microsoft confirmed they had seen multiple escalations with the same descriptions from other customers.  They have escalated it internally to multiple teams, Surface(device), Intune and Windows network teams.  

They had a theory that it could be related to Intune WLAN-Profile sync, although not confirmed.  They are still working on it and have not shared much else. 

We tested some internally and it seems to work a lot better on ConfigMgr systems, which also use EAP-TLS but with another cert chain, so it could be related. 

Lenovo has not shared much with us unfortunately, we have sent them logs on multiple occasions which they say has been sent to Intel engineers, not much else has been shared. 

I'll share more if we get anything useful. 

[Dezz]

Early days, but we've seen a significant improvement using the 24.20.0.4 and the Channel-Load usage for AP Selection set to Disabled (default is enabled).

This seems to 'fix' the issue by stopping the client frequently roaming between 2 APs. A number of other settings have also been changed (transmit power/roaming aggressiveness etc.) however, this is the only one which seems to have made any difference.  

[Robbyde]

The issues with us are the same but so sporatic.  For example we had the issue at one site and the next day the issue just stopped.

While they have the issue I've tried updating the firmware and taking packet captures.  Cisco are looking into it but dont have anything yet.

I'll try using the 24.20.0.4 and the Channel-Load usage for AP Selection set to Disabled 

[Dezz]

It's been the same with us @Robbyde, remote offices with ~12 users have 3 with dropouts all day and the next there are none. It's very odd.

We are now investigating a newish, recent issue with EAP-TLS timeouts which current thinking is due to framed-mtu settings from the NPS server hosted over the S2S VPN, incidentally where we see most dropouts. Whether this has been an underlying issue along the way I don't know yet but random users cannot connect first thing, retries fail and eventually they get on. This behaviour could be a symptom of the first EAP auth where they fully negotiate security parameters, validate certificates, and exchange keys and subsequent auths are pre-cached - unsure at the moment. 

Not an Intel issue as such, as we have seen it on the Realtek dongle substitutes, just thought I'd mention it. 

[Random123]

Something similar happens to us. We tried different WLAN driver configurations, such as disabling WoLAN and Power Save settings, but the issue still happens, we even though it was PMF feature related, but no luck. The only information we are sure is that it usually happens around 30min to 1h of the end-device first connection and not happens again across the day.

[Dezz]

@Robbyde @harfri @WayneD - have you had any luck with these issues lately?

[Robbyde]

I updated our controller to 17.15.4d and the clients to the latest version of intel and one of the sites hasn't had an issue for two weeks.

The other site says it's been a week so I'm hopeful it's fixed.

The Cisco TAC engineer seemed to think this combo was the fix.

[WayneD]

Early days.   We've spoken with our laptop fleet manufacturer this morning and their understanding is that one of the changes made by Intel in the v24.30.1.1 driver should result in a reduction of roaming aggressiveness.  We've started installing this driver on selected tester laptops within our corporate network.  The Network Engineers are monitoring the connections of the testers, supplemented by Wireshare and Intel WRT (Wireless Reporting Tool) running on the tester laptops.  There seems to be a general reduction of roaming movements but we still appear to have some incidents of disconnection occurring.  We only have a handful of testers at this stage however.

[harfri]

We also see improvements with the 24.30 driver and the Cisco OSX 17.15.4d , however the issue is not resolved, but the drops are much shorter. 

We have also tested the 24.40 driver, and this seems to perform much worse when we tested it.  We have collected logs and forwarded them to Lenovo, they have an escalation with Intel Engineers.  

Could be negatively impacted by our forced roaming test-method however, it may not be a very realistic use case. But if we do the same test with an older NIC it is WAY more stable.