Intel(R) Wi-Fi 6E AX211 160MHz Roaming between the AP in mesh network.

[Baskaran_Ganesan]

Hello Team, 

We have Meraki CW9166I and CW9176I in our mesh network. Most users' laptops are Lenovo X1 and Dell XPS/MAC M2/. A Common issue is roaming from one AP to another very frequently, causing a disconnect on the internet.  

Intel(R) Wi-Fi 6E AX211 160MHz is common on Windows laptops. We have the same issue with MAC Laptops, too. IT has a really hard time identifying the issue. 

[stapi]

Hello All,
We seem to have the same issue with Dell laptops with Intel(R) Wi-Fi 6E AX211 160MHz and Juniper/HPE Mist AP47 access points. MacBooks and older Dell laptops are fine. Also no issue when connected to older Mist APs, i.e. AP43. Anyone managed to get to the bottom of this?

[Cedric64]

It seems we are exactly in the same configuration for thousands of Dell devices for our company (Meraki APs in Wifi 6E/7, Dell Latitude devices with Intel AX211 160Mhz like Latitude 9430, Latitude 5440...). We tried several versions of drivers, including Dell latest ones, bu also Intel latest ones, nothing fixed it : these devices are constantly switching from 5 to 6ghz, regardless of the distance from the AP, and other devices in the same room with another Wifi 6E chip are not having the issue.

Curiously, we also have an HP EliteBook 8 G1i 14' with an Intel AX211 160mhz (brand new device), and it doesn't seem to be affected by the issue in the same room, maybe a revised version of this chipset ?

[Cedric64]

Can you please escalate the issue as it is affecting a lot of corporate devices ?

[Dezz]

This is definitely a roaming issue with the Intel AX and BE cards/drivers which no amount of setting changes or driver updates seems to help. There are multiple instances of this issue logged on this forum, including the one I've been trying to get Intel input from for months: https://community.intel.com/t5/Wireless/Long-term-dropouts-with-Intel-AXxxx-amp-BExxx-chipsets/td-p/1733389

Out current workaround is to use Realtek USB dongles which stops the dropouts (possibly due to less roaming) but we can't use this fix for 800+ clients... 

[WayneD]

We've observed the same symptoms as described in this thread.  We are running an Arista wireless infrastructure that is broadcasting our corporate WiFi 6E mesh in both 5Ghz and 6Ghz bands, and our laptops connect to the hotspot with EAP/TLS certificate-based authentication.

We are observing that Windows machines fitted with Intel wifi (we have approx 4000 laptops in the affected offices with Intel AX211 160Mhz chips fitted) are continually roaming between Wireless Access Points across the floor,  and occasionally dropping connectivity when doing so.

Laptops fitted with non-Intel wifi do not appear to be impacted.

We've been able to stabilise the situation by disabling the 6Ghz band on the network (leaving the 5Ghz band enabled).

We have just completed a 14-day investigation with Arista's engineering team that has identified the Intel driver as the most likely root cause.

[Dezz]

@WayneD we've seen a significant improvement with the changes made in another thread. We also disabled 5GHz as part of the troubleshooting to no avail. 

[WayneD]

Thanks for the tip, @Dezz.   Will test this config and return our findings. 

[stapi]

We have observed some improvement on the BE201 adapter after installing the latest Intel driver v24.20.0.4

However, the new driver has not made any noticeable difference for the AX211 adapters. We are currently testing with the “Channel-Load usage for AP Select” setting disabled (as suggested by Intel support). Initial results appear promising, but we need additional testing time to confirm whether this resolves the issue.

[Cedric64]

I tried the latest driver with this new setting set to disabled, but it didn't work, my users are still experiencing several disconnections during the day. Did you set this setting with other specific changes in advanced settings, from the defaults ?

[Random123]

Hi,

We are experiencing a similar issue with random disconnections. Have anyone got any solution or official support documentation?

Thanks.

Kind regards.

[SB21]

Hello Intel Support Team,

I am reaching out regarding roaming instability observed with the Intel(R) Wi-Fi 6E AX211 160MHz adapter (driver version 23.160) in an enterprise wireless environment. We have upgraded to 24.20 version but it did not fix the issue.

We are currently operating a WLAN using Juniper Mist infrastructure with the following configuration:

• Security: WPA2/WPA3 transition mode (mixed)
• 802.11r (Fast Transition): Enabled
• 802.11k/v: Enabled

In this setup, clients equipped with the AX211 adapter are experiencing both excessive roaming and failed fast transition events.

Observed behavior:

• Frequent roaming between nearby access points (ping-pong behavior), even when RSSI remains stable (around -60 to -70 dBm)
• Repeated FT authentication failures during roam attempts
• Fallback to full authentication, causing noticeable delays
• Roaming loops triggered shortly after failed transitions

Example log patterns:

• "FT authentication failed (status code 43)"
• "PMKID not found"
• "Fallback to full authentication"
• Multiple roam events within seconds between the same APs

From our analysis, the issue appears to be related to how the AX211 driver handles WPA2/WPA3 transition mode in combination with 802.11r. Specifically, there seems to be inconsistency in key selection (WPA2 vs WPA3) during fast transition attempts, resulting in authentication failures and unstable roaming decisions.

We have confirmed: The issue is primarily observed on AX211 clients

Could you please advise:

1. Whether this behavior is a known issue with driver version 23.160 up until 24.20
2. If there are recommended driver versions or settings to improve roaming stability
3. Whether there are known limitations with WPA2/WPA3 mixed mode + 802.11r on AX211
4. Any debug tools or logs you would like us to collect for further analysis

We are happy to provide additional logs, packet captures, or client diagnostics if needed.

Thank you for your support.

Kind regards,

[WayneD]

I notice that Intel released an updated WiFi driver :  version 24.30.1.1

Release Notes say it has "Better wireless stability and connect performance".   No other detail provided apart from that.

[Peter324]

Same issue for my company.

In Cisco Meraki Dashobard we can see x2 big issues :

- Frequent useless roaming between x2 AP both at the same distance from the Laptop which is not mooving.

- STA decide to disassociate and stay unassociated for up to 24 seconds before associating again with the same AP (?!)

This is the worst case scenario for a WiFi client this is exactly what the WiFi driver should be programmed to prevent at all cost.

During this time RF environment quality stayed the same, there is no reason for acting like that.

It occurs multiple time per day there is no logic behind it.

I focus my investigation on x2 Dell Laptop with BE200 and BE201 running Intel drivers 23.160.0.4 AND 24.20.2.1 and with default Intel Driver config.

I see that that a new driver has been released (24.30.1.1) as @WayneD  said, I will test it.

[Dezz]

@SB21  it sounds like you have followed the same path as us for months if not years. the 24.20.0 driver and the Channel-Load usage for AP Selection set to Disabled  certainly seemed to help by stopping the constant roaming which I feel only covers the real issue rather than addresses it. 

So far, we're seeing far less roaming so virtually no drops - I'll test the latest driver without it. 

[WayneD]

We've disabled the 'Channel-Load usage for AP Selection' setting on some laptops utilising the Intel AX211 driver and immediately noticed a reduction in the frequency of the Access-point roaming on our Arista wireless network.   The yellow line in the below chart taken from our Arista reporting console shows the pattern change on a laptop connected to our wifi network when the 'Channel-Load usage for AP Selection' was disabled.  This test was run from roughly 8am to 2pm on a day when we had full staffing in the office (ie. high-utilisation on the wifi network).  

Our theory is that the large number of WAP roaming events was caused by a conflict in the algorithms of the Arista network and the Intel driver - where both had a feature that was attempting to balance load across the available WAPs based on a utilisation measure. 

We notice that Intel have now released version 24.40 of the driver, and the release notes state that the default state of the 'Channel-Load usage for AP Selection' setting is now disabled.   This seems to confirm that this setting was a key contributor to excessing roaming events occurring in certain enterprise wifi networks.

[WayneD]

Tagging @SB21 SB21 for the above....

[Antonio12]

We are experiencing a similar problem.

We are migrating from Aruba to Fortinet. From day one, clients connecting to FortiAPs experience random disconnections, especially when there is some load on the channel. It mainly affects devices with the AX211 card (the vast majority), but others with the AX201 are also affected.

What is really peculiar, at least in our case, is that I can easily trigger the disconnection by initiating a file transfer from the client to a remote server. Even more strange, sometimes by doing that I disconnect a different device from the WiFi, connected to the same AP.

I have tried everything, from changes to band steering/AP handoffs settings, to disabling 2.4Ghz, to setting channels to 20Mhz only. Nothing seems to consistently work.

What I noticed is that, when the network is under some load, performance really drops and the client tries to roam (either to a different AP, or to a different band on the same AP). However, in my opinion, this is not the cause of the problem. Rather, a consequence from experiencing network instability, that is caused by something else.

We are using WPA2-Enterprise, but the same thing happens on WPA3-Enterprise.

The exact same device don't experience any problems with an external TP-Link adaptor.

It is really frustrating because we have had to halt the deployment of these new APs and stay with the much older Aruba ones until a solution is found.

[WayneD]

When you say "easily trigger the disconnection by initiating a file transfer from the client to a remote server", then that sounds like it could be related to the LSO (Large Send Offset) feature of the driver.