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?
Solved! Go to Solution.
Are both sets of devices using the same RF profile? Can you see anything in the event logs?
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 |
|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 |
|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
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.
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.
If you want good WiFi - don't by Surface Pro's.
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.