Clients sporadically cannot connect to Wi-Fi networks created by MR53E.

[Bri_Bri]

I'm trying to help administrate an office that has a single MR53E in it providing its Wi-Fi network. The various SSIDs use WPA2, are dual band 2.4 / 5 GHz, are setup to allow 802.11g connections or later, and are configured to be in bridge mode so that our MX84 can manage the network.

Most of the time client devices are able to connect to this network without issue. However, every now and then a client will lose their connectivity, and when checking available Wi-Fi networks will see that our Wi-Fi network is not available. Then some minutes later it will come back and their device will reconnect. There doesn't seem to be any rhyme or reason as to which devices experience this problem: it has happened to smart phones of various makes and models as well as several different laptops. I've also found no pattern as to when it happens -- it seems to be fairly random.

There is also a few devices that cannot see the Wi-Fi network at all. I'm fairly certain that these devices possess the necessary capabilities to connect to our network (802.11g or newer, WPA2, etc.) and yet they can't connect.

While there are a lot of competing Wi-Fi networks in the area, the MR53E is set to automatically select a channel to avoid interference so I'm not sure what I can do there to improve things. In case it's a clue, whenever I turn Wi-Fi off and back on again on any of my devices, these other Wi-Fi networks are displayed almost immediately, while the ones created by our MR53E take 5-10 seconds to show up.

I'm quite new to all of this so I'm not sure what I should do to try and get to the bottom of this issue. Any suggestions would be much appreciated!

[NolanHerring]

What switch is the MR53E connecting to? Can you check logs on that to see if the port is flapping causing the AP to reboot within a few minutes (which you won't usually see on the dashboard). If you contact support they can tell you what the uptime is on the AP in question as well.

What antenna are you using? Is it mounted in a good location?

Do you see anything in the AP event logs that stands out? Is it using a DFS channel and maybe its detecting radar and then moving away because of that?

I would open up a simple wireless scanner near the AP and just find the cleanest channel on 5GHz and hard code that in personally.

What are the data rates that you have configured on the SSIDs for the devices that do not see it at all? Those devices may only operate on 802.11b. Or if the AP is on a DFS channel, the clients may not support those channels.

Safest bet is to use UNII-1 or UNII-3 bands. (36/40/44/48, 149/153/157/161)

[Bri_Bri]

@NolanHerring to answer your questions:

The MR53E is connected directly to a port on the MX84. I'll check the logs about port flapping when I have the chance, but that's probably not it since when this problem occurs it only affects one device at a time rather than all of them.

The antenna are Cisco brand dipole Antenna (MA-ANT-3-B6). I believe the AP is in a good location. All the devices report strong to very strong signal strength.

I don't believe any of the devices that can't connect are 802.11b only. Not sure about DFS -- will look into that.

I haven't had a chance to really dig into the AP logs so far, but I agree that's a good place to look for issues.

Thanks for all the suggestions so far.

[PhilipDAth]

Does Wireless Health say anything interesting?

When you say a client can't connect - do you mean a single client can't connect but others still can (and are) connected - or that no device can connect?

[Bri_Bri]

@PhilipDAth

The issue is that a single client won't be able to connect (temporarily) but the others still can.

Wireless Health does mention some connection failures. I'm not sure how to interpret the logs, though. Most of them seem to be Association and Authentication failures. here's a small selection of them:

Authentication type='WPA-PSK auth fail' associated='false' radio='1' vap='1'
Authentication type='WPA-PSK auth fail' associated='false' radio='1' vap='3'
Association type='Association attempts' num='3' associated='false' radio='1' vap='3'
Authentication type='WPA-PSK auth fail' associated='false' radio='1' vap='2'
Association type='Association attempts' num='4' associated='false' radio='1' vap='2'

[PhilipDAth]

The fact that only individual clients at a time are being affected is a big one.

The log below "PA-PSK auth fail" indicates that the RADIUS server is refusing to allowing the client to connect.

You need to check the logs on your RADIUS server to determine why.

If you have a non-standard password lockout policy what can sometimes happen is when a user changes their AD password but doesn't change it on their device it triggers the account to get locked for a short period of time, resulting in the RADIUS server refusing the connection.

The RADIUS server log will hold the key to the issue.

[Bri_Bri]

@PhilipDAth I don't believe we're using a RADIUS server or WPA2 Enterprise. We've just got the SSIDs association requirements set to "Pre-shared key with WPA2".

[PhilipDAth]

Interesting.  So the question is why is the auth failure happening.

What firmware version are you running on the AP?

You are not running any other brands of AP as well at the same site using the same SSID?

[Bri_Bri]

On the MR53E it says it's firmware is up-to-date, version MR 25.13.

The MX84 has a firmware update available that I haven't installed yet.

There are no other APs running in this office. However we used to have a consumer grade AP (not sure what model) that was providing a Wi-Fi network using the same SSID as the MR53E is now. I've since created a few other SSIDs on the MR53E just in case that was causing issues, but on any device that experiences this problem, all of the SSIDs provided by the MR53E disappear, not just the one that used to come from the older AP.

[Bri_Bri]

@PhilipDAth Another bit of info: the two devices that couldn't connect at all were a cheap $40 Android prepaid phone and an old iPod Touch 3. When I created an SSID that used either no encryption or WEP they were both able to connect to that, so I'm guessing that they don't use a modern enough version of WPA2 to be able to connect to our other SSIDs. Does that sound right?

(For those that might be concerned about the security of my wireless network, don't worry, I'm not going to keep an unencrypted or WEP SSID up. That was just for testing.)

[PhilipDAth]

Perhaps try enabling WPA1 as well.

[Bri_Bri]

After a few days of no incidents, today we had several devices suddenly become unable to see any of our SSIDs. After about half an hour one of the devices started to be able to see one of the SSIDs again, but the others still couldn't. Someone at the office rebooted both the MR53E and the MX84 and it cleared up the problem.

I'm starting to get quite concerned about this. So far this equipment is working worse than the consumer grade wireless router we were using previously! Does anyone have any other ideas as to what could be going wrong?

While this was happening, there were more "Failed connections" entries in the wireless health page for the MR53E:

Thu Jan 10, 2019, 16:28:33  client1          Wireless Access Point   SSID1   Authentication  type='WPA-PSK auth fail' associated='false' radio='1' vap='0'
Thu Jan 10, 2019, 16:21:03  desktop-client2  Wireless Access Point   SSID2   Authentication  type='WPA-PSK auth fail' associated='false' radio='1' vap='2'
Thu Jan 10, 2019, 16:20:23  desktop-client3  Wireless Access Point   SSID1   Authentication  type='WPA-PSK auth fail' associated='false' radio='1' vap='0'
Thu Jan 10, 2019, 16:20:13  android-client4  Wireless Access Point   SSID1   Authentication  type='WPA-PSK auth fail' associated='false' radio='1' vap='0'
Thu Jan 10, 2019, 16:16:43  client5          Wireless Access Point   SSID1   Authentication  type='WPA-PSK auth fail' associated='false' radio='1' vap='0'
Thu Jan 10, 2019, 16:11:23  desktop-client6  Wireless Access Point   SSID1   Authentication  type='WPA-PSK auth fail' associated='false' radio='1' vap='0'
Thu Jan 10, 2019, 09:29:42  client5          Wireless Access Point   SSID1   Association     type='Association attempts' num='3' associated='true' radio='1' vap='0'
Thu Jan 10, 2019, 09:29:22  client5          Wireless Access Point   SSID1   Authentication  type='WPA-PSK auth fail' associated='false' radio='1' vap='0'
Thu Jan 10, 2019, 09:28:52  client5          Wireless Access Point   SSID1   Authentication  type='WPA-PSK auth fail' associated='false' radio='1' vap='0'

(I've changed the device names, MAC addresses, and SSID names for privacy reasons.)

I'm afraid I do not understand what those error entries mean, aside from there being some kind of authentication issue.

Is there anything else we can do to address this?

[NolanHerring]

Can you show a screenshot of the event log for the AP in question. Its possible the radio is no longer working. Also show a screenshot of the RF tab, that would show you if clients just 'dropped' for that window of time.

[Bri_Bri]

@NolanHerring I've attached two screen shots. The problem was reported to me around 16:00 on January 10, and the screen shot I took of the event log is from around that time.

[NolanHerring]

So I was looking for a very obvious symptom that I'm quite familiar with where the 5GHz radio simply stops working. I don't see that happening. Plenty of clients still actively using the AP, so I can't help but want to lean towards a client related issue in this case.

[Bri_Bri]

I've been looking for some kind of client-related explanation too, but as I've mentioned there's no connection or commonality among the clients this happens to. These are all devices that have no trouble connecting to other wi-fi networks.

I'm starting to think our AP is defective. I'll probably contact Cisco support directly at some point in the not too distant future.

[Bri_Bri]

So I think I figured out the issue: I had set up my SSIDs to only accept 802.11g connections and later. Apparently that causes a lot of devices to become sporadically unable to connect, even though they're not 802.11b devices.

Once our SSIDs accepted all connections including 802.11b the issue magically disappeared. I thought I'd post about it here for posterity.

[NolanHerring]

Hmm...well thanks for the update but I can't help but to think that more than half of the Meraki networks out there are doing just that, using 12Mbps as minimum etc., in order to disable 802.11b

Do you by any chance have MESHING disabled?

Also, what version are you on because I had to have my MR52 upgraded to 26.X about a month ago (after they had been running for like 4 months) because they kept rebooting randomly.

[PhilipDAth]

Every single one of our clients is configured to use a minimum bit rate of 12Mb/s - and none of them are reporting an issue.

[NolanHerring]

Also are you running 80MHz by any chance?

[MarcusMusgrove]

Hello. Has there been any kind of solution to this issue. I am seeing similar issues with authentication on all of our wireless networks.  Two of them are for guest users and just use a WPA2 pre-shared key. The other is for our corporate devices and uses RADIUS to authenticate using Cisco ISE. The ISE does not report any issues. 

The errors i see in the Meraki Dashboard under wireless health are the same that were reported in the original post. 

Any further information would be greatly appreciated.

[Bri_Bri]

To answer some of the questions that other people posted after I posted my solution, our SSIDs were configured only to accept 802.11g and later connections, meaning the minimum bitrate was 54 Mbps, not 12. It could be that setting it to 12 Mbps would work fine for us, but I haven't changed it since I set the minimum back to 11. We have no reason to forbid 802.11b devices (and no one is using one anyway) so I'm not inclined to change it.

Both our router and AP are running the latest firmware and were at the time we were having a problem. The AP's channel width is set to auto. We are not using meshing.

[NolanHerring]

---

@Bri_Bri wrote:
To answer some of the questions that other people posted after I posted my solution, our SSIDs were configured only to accept 802.11g and later connections, meaning the minimum bitrate was 54 Mbps, not 12. It could be that setting it to 12 Mbps would work fine for us, but I haven't changed it since I set the minimum back to 11. We have no reason to forbid 802.11b devices (and no one is using one anyway) so I'm not inclined to change it.

Both our router and AP are running the latest firmware and were at the time we were having a problem. The AP's channel width is set to auto. We are not using meshing.

---

So keep in mind, that slider is strictly for management frames (beacons/probe response/probe request etc.).

If you had the mandatory data rate set to 54Mbps then I could see how that would cause issues. I wish they would remove the option to go higher than 24Mbps personally. And even then, that should only be used for true VHD designs.

The 802.11-2012 (Section 18.2.2.3) standard mandates that devices (clients/access points) need to be able to support the following management frame data rates (6 / 12 / 24). So if your ever going to change your mandatory data rate (the rate at which your beacon frames will be sent at for example), you will want to choose one of those 3 options.  You could set it to say 36 for example, but your going to potentially run into situations where clients do not like that, and have issues connecting.

Within Meraki access control settings, the slider limits you somewhat. If your SSID is 5GHz only, then you don't need to worry about 802.11b rates. If your SSID is dual-band, and you have no need to support 802.11b, then you'll want to set it to 12Mbps.  Leaving 11Mbps or below will add more overhead, decreasing your potential airtime. 

If your using RF Profile then you can change it per band, but basically if you have no need for 802.11b support, then kill it to improve overall performance by removing that useless airtime overhead. The 11Mbps frames take 'longer', thus reducing airtime for everyone else.

You can use this airtime calculator to see first hand how much airtime is consumed by management frames:

http://www.revolutionwifi.net/revolutionwifi/2013/10/ssid-overhead-how-many-wi-fi-ssids-are.html

If your slider was set to 54Mbps, then you may have run into one of two things:

1. Your clients may not have played nice with this setting and it caused general connectivity issues because clients did not care for 54Mbps as the mandatory data rate (driver issues etc.).
2. Your wireless coverage for management frames may have 'shrunk' too small, so clients moving from AP to AP were missing frames from nearby potential access points to roam to.

Increasing this threshold will in theory shrink the 'management cell size', but not the actual cell size. Your 'real' cell size is always the same, so changing the mandatory data rate doesn't actually decrease CCI/CCC since PLCP preamble and headers are always sent at lowest modulation data rate (6Mbps for 802.11g and 802.11a).

Safe rule of thumb is to not go higher than 12Mbps and you should be fine. 

PS - I typed the word 'management' about a dozen times above, and I had to use auto-correct every single time. Am I the only one that has trouble typing that word lol

[J1024]

So, I'd like to add some comments/questions to this discussion since I finally feel like I'm not alone in the world.

Starting several months ago (mid December, I believe?) we started experiencing issues with our Meraki APs where clients couldn't connect to the WiFi... but they could. They would connect just fine, but their devices would fail to get DHCP leases. However, the experience for the clients is exactly as described: Everything is working fine, some clients sporadically drop connection and when attempting to reconnect the WiFi 'doesn't work'. We figured out early on that there were two things that could resolve this issue: Rebooting the AP that they were connecting to, AND/OR under "Client IP assignment" changing between 'Layer 3 Roaming' (what we've used since setting up Meraki years ago) and 'Bridge Mode'; Doesn't where it was set, changing the setting to the other, or changing it and changing it back would allow devices to reconnect. And I do mean 'AND/OR'; sometimes just one would work, sometimes the other, sometimes we would have to do both. I haven't tested them individually in awhile though, I just do both by default now.

We have multiple Networks with APs, but only one is effected, and all the SSIDs of that Network seem to be effected. Because of the structure of our organization, most of the APs in our networks are all on the same management subnet, and assign addresses to the same DHCP ranges for our 'private' networks and our 'public' networks, but again only one 'network' is seeing these issues.

I opened a support ticket with Meraki a few months back but they refused to move past the Event Log having entries of 'Multiple DHCP Servers Detected', but those 'errors' existed long before we had these issues and also all have the identical MAC address and are just pointing from the gateway to the IP Helper address, so I don't believe there are any issues there.

Sorry if this is hijacking this thread, we've just been dealing with this for months and I finally found this thread after checking out the network health page and searching for one of the auth errors it gives. We're also using WPA2, and some SSIDs use Radius and some use PSK, so nothing solid there either. Also, the 'minimum bandwidth' on our SSIDs is all 11 or lower, and the majority of the devices having issues are brand new Surface Go tablets or Samsung S7/iPhone 8 (or newer) phones. We also had made no changes to our network structure, SSIDs, DHCP, etc around this time, so there was no trigger to the start that we were aware of... it just started happening one week.

[FiberOps]

Has anyone found a solution to this? This sounds exactly the same as the issues we are experiencing for months now, mainly with MacBooks but also some PCs. Clients boot up their macbooks and connect to our APs just fine then randomly thought the day some users will lose their wifi connection.

Also if user is connected to wifi, with macbooks, then closes their lids and moves to another area serviced by another AP this will also happen. Their macbooks looks to be connected for a minute or so, and then they get disconnected and prompted for credentials, even though their credentials are saved. Below is what shows up in the event logs. I've noticed this only happens to certain APs that are configured identical to the rest.  

Strange thing is, when clients don't close the lid and roam normally, they DON'T have this issue. They just roam seamlessly between APs with maybe 2 or 3 ping drops. 

We currently have a mix of MR53s and 42s with the latest firmware.

We using RF profiles:

• Per AP-Dual band with Band Steering
• 2 SSIDs (guest -wpa2 /employees - radius)
• 20 MHz channel width
• Auto Channels for 2.4 & 5 band
• Custom Targeted Power to avoid signal overlap 

I've also found this thread https://community.meraki.com/t5/Wireless-LAN/802-11-disassociation-client-not-authenticated/td-p/552... with much of the same reported issues. This issue was resolved by disabling all HP printers  with direct wifi enabled. Is there any merit in this? I don't want to go down another rabbit hole. 

[J1024]

@FiberOps 

Just to provide some follow-up to my issue, somehow SOME of our APs were on a beta firmware.... which apparently had 'known issues with disconnects'.... somehow it took three tickets with Meraki support before anyone mentioned that.

Reverted back to stable/released firmware and no longer had the issue, magically. I forget where it was exactly, but it was a simple checkbox within the network settings I believe, but I forget how it was only applying itself to some of the APs within that network.... and not the whole network, or multiple networks. We also weren't experiencing issues specifically with Macs, although we don't run Macs so they might have also had the same issues.

You mentioned 'custom target power to avoid signal overlap'. With Meraki APs is signal overlap a bad thing? I thought overlap was good (to some extent) so that APs could hand off clients smoothly?

[FiberOps]

So unfortunately the firmware isn't the issue we are having. So in our environment it is a high density deployment so there was 4-5 signals overlapping, which was why i changed to custom power. 

[rrocha]

I am experiencing the same issue in a home network with a simple wpa2-psk ssid.

The few clients, from time to time, are in the lwireless heath log about auth failling and association fail.

I was experiencing at the same time problems relate do the PoE source with the MR30H, because not using the 802.at the 3rd radio will kind of be disabled and it will changing the factual transmit power too.

After changing the power source, only the auth and association fail is happening, so I will change the bit rate as you said to see if will correct in my home environment too.

[rrocha]

Okey, just a report to keep everybody updated about the change of bit rate...

In my case there was not changing..

In Wireless Heath, there is no correlation about changing the bit rate and the number of connections problems around association and auth in a ssid with wpa2-psk network.

There is still a Windows Surface experiencing the problem about auth from time to time, and a macbook experiencing more about association problems...

[colby_oc]

Did anyone ever determine definitive resolutions for this?  I've recently taken a job where I'm managing Meraki AP's for the 1st time.  I've found the biggest noticeable impact to users are Teams/Zoom calls, however connectivity to the FileMaker server is also noted.

I have a large mix of affected clients, mac/pc, most of the PC's are newer Dell XPS systems with a flavor of the Killer Wifi card. 

I put in place a Unifi AP to confirm my theory that these AP's are the problem, I just can't figure out where the problem is.

I get the most complaints from the building full of MR45 access points. (firmeware is currently utd with MR 26.8.1, but they are getting updated to the beta MR 27.5 tonight, per Meraki)

Most Common Errors in the AP Event Log

Authentication - Client failed during the authentication step.type='WPA-PSK auth fail' associated='false' radio='0' vap='0'      &

802.11 disassociation - unknown reason

I have a test SSID and I'm more than happy to try just about anything as even though I have an active support ticket with Meraki, they haven't been that helpful.  Most all things about the setup here are default, the testing SSID is set to 5ghz only, issues persisted.  The production SSID I changed from Dual band to Dual band with band steering, issues persisted.  Production is set to Bridge mode and the Minimum bitrate is 11Mbps.  

Hoping for help.....

[cmr]

@colby_oc do the Dell XPSes have Killer(Intel) WiFi5 NICs, if so do they drop when on battery or also when wired?

[colby_oc]

Both on battery and power.

Also I've did have a case open with Dell, they provided me an Intel Driver that does appear to help some, but definitely still problems persist.

Yet with the exact same laptop I can have a 45 minute long Teams Video call with no issue when connected to the Unifi network I put in place to confirm the issue is somehow these AP's.

[colby_oc]

For what it's worth...the Dell XPS systems seem to predominantly have the Authentication - Client failed during the authentication step.type='WPA-PSK auth fail' associated='false' radio='0' vap='0' error, while the mac laptops seem to have the 802.11 disassociation - unknown reason error.

[NolanHerring]

If I'm being honest, I am like 83% certain that the entire line up of the GEN-1 Wi-Fi 6 access points should be removed from production and replaced with the 2nd gen, at Meraki's cost (MR45/55).  I've never seen anyone with a successful deployment of those things. Not to mention there really is ZERO reason to ever buy them, they are only Wi-Fi 6 compatible, not certified.  I see the MR55 is no longer on their website, but MR45 still is. 

[colby_oc]

@NolanHerring Can you tell me what model you would recommend? I have confirmed that our newest remote site, which has a cloned SSID setup with an MR33 does not have issues. 

I would LOVE it if it's a hardware problem and I could get Meraki to replace them with a new generation device but I fear that convincing them won't be easy. 

I do feel pretty strongly though that when I can buy a $100 device and have significantly better performance that this equipment has to be the issue.

[colby_oc]

@NolanHerring do you have an opinion on the MR42?  I'm seeing the authentication error on that AP as well which is in a different building and the only AP there.  There are limited users in that building and unfortunately previous "resolutions" put in place for these users was to wire them in.

[NolanHerring]

---

@colby_oc wrote:

@NolanHerring do you have an opinion on the MR42?  I'm seeing the authentication error on that AP as well which is in a different building and the only AP there.  There are limited users in that building and unfortunately previous "resolutions" put in place for these users was to wire them in.

---

I believe there is a known bug about this specific thing, which I can see in the 27.X firmware release notes. Not sure if it applies to 26.8.1 though.

• Under certain conditions, successful WPA2-PSK connections are reported as failed under Wireless Health event logs (All MRs)

[NolanHerring]

@colby_oc  - I hesitate to make any recommendations, but I know MR42 are solid. I've had a few bumps with MR52's rebooting like Christmas tree lights in the past for unknown reasons (25.x train).

I believe the MR36/46/56 have been relatively solid based on forums feedback (certainly better than the 45/55 models). But its Wi-Fi 6, and that's new tech and going to have bugs, as you have clearly seen from their GEN-1 series.  If your not really gaining anything from Wi-Fi 6 yet (and you most likely aren't) then it might be safer to fall-back to tried and true Wi-Fi 5 models. 

I prefer stability over new tech.

[J1024]

--"Did anyone ever determine definitive resolutions for this?"

Only as much as previously mentioned; some of our APs were on beta firmware, getting back to main branch resolved our issues. We use MR18/32/33 and one 74 though. We do have occasional issues with Microsoft Surface Go tablets being unable to connect to the APs, but very sporadic and rebooting the AP resolves the issue. Uncommon enough that we haven't looked for further resolution though.

[colby_oc]

Thanks for the reply.  I updated to the beta firmware the AP's on the most affected/reported network which is full of mostly MR45's to MR 27.5, so far this has had a huge positive impact.  Testing with IS staff was very successful as well as a few other select staff members.  I do believe this may have solved the issues but I need to get more staff feedback before I can say that with closer to absolute confidence.

[J1024]

No problem. I always remember xkcd.com/979, 'Wisdom of the Ancients'; Always follow up on your forum posts. 🙂

[CarolineS]

---

@J1024 wrote:

No problem. I always remember xkcd.com/979, 'Wisdom of the Ancients'; Always follow up on your forum posts. 🙂

---

Love this comic! Maybe we'll add it to our reminder emails 🙂

[colby_oc]

Given I had only posted a few days ago it takes time to test and I did update that it was going well, pretty sure he did not merit those kudos' but whatever bigger fish to fry.  Updating more of my other networks as well as this beta firmware does seem to be working well.

[CarolineS]

---

@CarolineS wrote:

---

---

Love this comic! Maybe we'll add it to our reminder emails 🙂

---

You should now see this comic in our "Accepted Solution Reminder" email (with permission from XKCD). Thanks for the inspiration, @J1024! 

Source: XKCD https://xkcd.com/979/

[colby_oc]

For all interested parties I'm happy to report that it appears after much effort this issue is now resolved.  At least my end users are not experiencing the same issues.  While the authentication error is still present, I'm told that it's a false alert for our encryption type.  The biggest improvement was noticed after some tweaking to the power settings and the channel widths at the advisement of a Meraki support tech.  This is due likely to our own bad decisions of putting too many AP's too close to one another, but none the less things do seem stable now.

[J1024]

You just made my day with that..... 😀

Thanks to you, the Meraki Community, and of course Randall Munroe!

[CarolineS]

---

@J1024 wrote:

You just made my day with that..... 😀

Thanks to you, the Meraki Community, and of course Randall Munroe!

---

Any little thing helps this year, right!?

[redsector]

Still having WiFi6 accesspoint issues?

have a look here:

https://community.meraki.com/t5/Wireless-LAN/poor-WLAN-quality-with-MR45/m-p/100512#M14855

[SchoolITMan]

10/21/2020:  We are having this same issue with repeated authentication issues on our network.  We are using MR42 APs and MS120 Switches.  The issue has been happening for approximately 5 weeks - about the time that we updated firmware to MR 27.5

Oddly, this is happening in only 1 of 2 buildings on the same network, with the same equipment, with the same radio profiles, broadcasting the mostly same SSIDs.  And while it is happening to everyone sporadically, it is happening much more often (several times daily) to 2 groups of teachers & their students in two different corners of the school on 4 different APs and 2 different SSIDs, with different authentication between teachers & students.  (Students are WPA2-PSK and Teachers are 802.1X with Meraki RADIUS)

Also, our Meraki cloud access seems to be getting slower and slower...

[Termont]

Wow! Long thread. Had very similar symptoms.

My problems started after noticing that one of our SSID had legacy WPA authentication configured. Changed it to WPA2/WPA3 but that forced users to reauthenticate and flooded the support desk. Word to the wise, always send a notice first...cuz users.

Anyways, I've put the settings back were they were and all came back as before, except for a few clients experiencing the occasional disconnect or not being able to connect with their cell phones.

However, I had forgotten to put back ONE settings that, at the time, I thought, hey, let's try that...

802.11w

https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/802.11w_Management_Frame_Protecti...

Had left it enabled. Disabled it and all my problematic clients reconnected fine.
This thing is over 10 years old and does not seem to play well with others.

So still on WPA and no 802.11w. I know...

Thank you.