drop without reconnect when moving from mr34 to mr42

Getting noticed

drop without reconnect when moving from mr34 to mr42

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?


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.

View solution in original post

Kind of a big deal

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

Meraki CMNO, Ruckus WISE, Sonicwall CSSA, Allied Telesis CASE & CAI

All on same RF profile.

Sep 23 14:02:13DF03-WAP-PatchPanel45GonzoNetAlaskastone802.11 disassociationclient not authenticated
Sep 23 14:02:13DF03-WAP-PatchPanel45GonzoNetAlaskastone802.11 associationchannel: 11, rssi: 39
Sep 23 14:01:57DF03-WAP-PatchPanel44GonzoNetAlaskastone802.11 associationchannel: 153, rssi: 21
Sep 23 14:01:57DF03-WAP-PatchPanel45GonzoNetAlaskastone802.11 disassociationclient not authenticated
Sep 23 14:01:57DF03-WAP-PatchPanel45GonzoNetAlaskastone802.11 associationchannel: 52, rssi: 38
Sep 23 14:01:48DF03-WAP-PatchPanel43GonzoNetAlaskastone802.11 disassociationprevious authentication expired
Sep 23 14:01:46DF02-WAP-PatchPanel147GonzoNetAlaskastone802.11 disassociationclient was deauthenticated
Sep 23 14:01:46DF02-WAP-PatchPanel147GonzoNetAlaskastone802.11 associationchannel: 112, rssi: 28
Sep 23 14:01:43DF01-WAP-PatchPanel50GonzoNetAlaskastone802.11 disassociationclient was deauthenticated
Sep 23 12:16:58DF01-WAP-PatchPanel50 AlaskastoneEvents dropped57 events were not logged. 
Sep 23 12:15:00DF01-WAP-PatchPanel50GonzoNetAlaskastoneRADIUS responseradio: 1, vap: 2, group:   « hide
rtt0.000 ms
Sep 23 12:15:00DF01-WAP-PatchPanel50GonzoNetAlaskastone802.1X deauthenticationradio: 1, vap: 2, client_mac: XX:BC:XX:66:XX:28  « hide
Sep 23 12:15:00DF01-WAP-PatchPanel50GonzoNetAlaskastone802.11 associationchannel: 60, rssi: 51
Sep 23 12:15:00DF01-WAP-PatchPanel50GonzoNetAlaskastone802.11r associationradio: 1, vap: 2, resp: accept


50, 45, 44 and 43 are MR42's

147 is a MR34

Kind of a big deal

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


Have you checked for a driver update?

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.

Kind of a big deal

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.

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.

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.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.