drop without reconnect when moving from mr34 to mr42

[Spack]

We have 11 waps.  5@MR34 and 6@MR42

All WAPS running MR25.13 firmware

When people move from an area of the office that is served by the 34's into the area served by the 42's, it is becoming more and more common that people lose connectivity and cannot reconnect until they reboot. NPS/Radius is in use and auths without known errors anywhere on the network.  The reverse is not true.  People transition from the area of the building with the 42's into the area served by the 34's without issue. 

For example, they go from their office into an older section of the building (with MR34's) to attend a meeting and everything is great.  When they return from the meeting and get back to their office, (with MR42's) they cannot reconnect without rebooting.

Has anyone else experienced this?

[BlakeRichardson]

Are both sets of devices using the same RF profile? Can you see anything in the event logs?

[Spack]

All on same RF profile.

Sep 23 14:02:13	DF03-WAP-PatchPanel45	GonzoNet	Alaskastone	802.11 disassociation	client not authenticated
Sep 23 14:02:13	DF03-WAP-PatchPanel45	GonzoNet	Alaskastone	802.11 association	channel: 11, rssi: 39
Sep 23 14:01:57	DF03-WAP-PatchPanel44	GonzoNet	Alaskastone	802.11 association	channel: 153, rssi: 21
Sep 23 14:01:57	DF03-WAP-PatchPanel45	GonzoNet	Alaskastone	802.11 disassociation	client not authenticated
Sep 23 14:01:57	DF03-WAP-PatchPanel45	GonzoNet	Alaskastone	802.11 association	channel: 52, rssi: 38
Sep 23 14:01:48	DF03-WAP-PatchPanel43	GonzoNet	Alaskastone	802.11 disassociation	previous authentication expired
Sep 23 14:01:46	DF02-WAP-PatchPanel147	GonzoNet	Alaskastone	802.11 disassociation	client was deauthenticated
Sep 23 14:01:46	DF02-WAP-PatchPanel147	GonzoNet	Alaskastone	802.11 association	channel: 112, rssi: 28
Sep 23 14:01:43	DF01-WAP-PatchPanel50	GonzoNet	Alaskastone	802.11 disassociation	client was deauthenticated
Sep 23 12:16:58	DF01-WAP-PatchPanel50		Alaskastone	Events dropped	57 events were not logged.
Sep 23 12:15:00	DF01-WAP-PatchPanel50	GonzoNet	Alaskastone	RADIUS response	radio: 1, vap: 2, group:   « hide rtt 0.000 ms attr 11
Sep 23 12:15:00	DF01-WAP-PatchPanel50	GonzoNet	Alaskastone	802.1X deauthentication	radio: 1, vap: 2, client_mac: XX:BC:XX:66:XX:28  « hide client_ip 0.0.0.0 identity XXXXXXXXX\Xxxxx aid 837802717
Sep 23 12:15:00	DF01-WAP-PatchPanel50	GonzoNet	Alaskastone	802.11 association	channel: 60, rssi: 51
Sep 23 12:15:00	DF01-WAP-PatchPanel50	GonzoNet	Alaskastone	802.11r association	radio: 1, vap: 2, resp: accept

50, 45, 44 and 43 are MR42's

147 is a MR34

[PhilipDAth]

This is 99% likely to be a driver issue - especially if a reboot is required.

Have you checked for a driver update?

[Spack]

Surface computers.  The driver is all part of a gigantic package that installs all system drivers. There is no newer package.  Happens on surface pro 4 and surface book 6. Has happened on some hp laptops in the office but not near as often.

Thing in common they have is Intel WiFi.

[PhilipDAth]

Surface Pro 4's (and many of the others)  use the Marvell Avastar chipset,

This chipset is known to have significant non-fixable issues with roaming.  In particular they incorrectly cache the key used to encrypted the traffic when they briefly go out of coverage when roaming between access points, and don't respond to requests to clear the key.

Typically a user will see the connection working.  They move to another place briefly going out of coverage and then roam.  The new AP sends a new key to use.  The chipset keeps trying to use the old key.

So now the chipset is encrypting and sending data using the wrong key.  The AP can't decrypt it.

If you Google the issue you'll find it is a well known issue with Surface Pro's and affects all WiFi vendors.

https://www.reddit.com/r/Surface/comments/a5kly1/microsoft_please_source_a_new_wifi_chip/ 

If you want good WiFi - don't by Surface Pro's.

[PhilipDAth · Accepted solution]

ps.  You don't need to reboot the machine to restore the connection.  You can disable the adaptor and then re-enable it to resolve the issue.

[Spack]

Thank you kindly for your words of wisdom.  We had similar but not the same issue before with the intel adapters, several years ago.  A software update was able to fix them.  It sounds like no such beast is available this time.

Your honesty is greatly appreciated.