Random wifi disconnects happening for devices on a particular SSID and base station

SOLVED
Tintin
Getting noticed

Random wifi disconnects happening for devices on a particular SSID and base station

On one of our MR42 access points we have added an SSID that is separate from the one we use for the rest of our MR42 access points spread throughout the locale. Things has been working fine until about a month ago where the users of that SSID started to get seemingly random disconnects from the Wifi network on that particular SSID. The ones on the other SSID we use don't have this problem, but it's also worth mentioning that these are not often close to that particular access point.

 

What happens is that all of the devices connected suddenly drops the connection to the wifi and then it takes a while until it's possible to connect again. Sometimes the devices connects back automatically after about 30 seconds.

 

We haven't changed any setting or so, so I'm staring to think there might be some external interference or something.

 

All devices are on the current firmware as of this typing and everything looks green and healthy in the Meraki dashboard. Average channel utilization is ”low” to ”very low” for both spectrums (we only use 5 GHz though) and I can't see any obvious faults anywhere.

 

Several devices show as getting ”802.11 disassociation unknown reason” from time to time, but that is also seen on the other base stations where the wifi disconnects don't happen.

 

I have no idea where to start troubleshooting this.

 

I did use the ”Wireless Diagnostics” tool on one of the MacOS machines and it did come up with ”Conflicting Wi-Fi CC” being ”yes" – there are several base stations in the proximity (not ours) that seem to be set to use country code DE and FR while our is set to SE since we are in Sweden. Could that be the problem? What can I do about it in that case – I mean I'm not really in control of what settings people in the building where we're at use for their base stations.

1 ACCEPTED SOLUTION
Tintin
Getting noticed

All problems seems to have been solved since updating the access point to firmware MR 29.4.1.

View solution in original post

16 REPLIES 16
alemabrahao
Kind of a big deal
Kind of a big deal

Yep, It could the problem, but the 802.11r and 802.11w are set to enabled or disabled? What typo of authentication are you using?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

802.11w is disabled. Authentication is done via Pre-shared key (PSK).

Not sure where I find the setting for 802.11r, sorry. Is that about the roaming? I see Layer 3 roaming is enabled.

 

Edit:

 

Just disabled Layer 3 roaming. Not sure why it was enabled as we don't use that for any of the other SSIDs.
Hope that does it. 😄

alemabrahao
Kind of a big deal
Kind of a big deal

802.11r technology reduces overhead when a client roams from one AP to another, delivering a more seamless transition. "Enabled" will activate 802.11r for devices that support it, though some legacy clients may not be able to join the network. "Adaptive" enables a custom version of 802.11r just for Apple iOS devices. Very few devices will have compatibility challenges with the "Adaptive" mode. 

 

 

alemabrahao_0-1664970160133.png

I have never used L3 roaming.  was It solved?

 

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

Thanks for elaborating @alemabrahao🙂

Turning Layer 3 roaming off seems to have done nothing to wifi stability. 😞

 

Okay, I will try to enable 802.11r set to ”Adaptive” (found the setting now: Wireless -> Access control) and see if that changes anything. One setting change at a time. 🙂

 

Shall I enable 802.11w in some form otherwise you think? I guess I should read up more on what it does…

alemabrahao
Kind of a big deal
Kind of a big deal

The 802.11w amendment applies only to a set of robust management frames that are protected by the Protected Management Frames (PMF) service. These include Disassociation, Deauthentication, and Robust Action frames.

 

Some legacy devices that do not support 802.11w may not be able to connect to an SSID even if in mixed mode. This may be due to the device improperly handling the advertised information contained within the beacons.

 

Can you share how is configured your RF profile?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

This is how the RF profile currently associated with the access point looks like. I enabled ”band-steering” because ut was suggested when more than one SSD is used – was using only 5 GHz before.

Screen Shot 2022-10-12 at 16.12.44.png

alemabrahao
Kind of a big deal
Kind of a big deal

Take a look on this recommendations:

 

https://hcsonline.com/images/PDFs/Wi-FI_Apple_Devices.pdf

 

For Apple devices I really recommend a 5GHz only coverage design.

 

https://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/technotes/8-6/Enterprise_Best_Practice...

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

Thanks for the links.

 

I was using only 5 GHz before, but changed to band steering because it said that was recommended when broadcasting more than one SSID.

 

The thing is, when the ”disconnect” happens it also applies to a computer running Windows, so it doesn't seem operating system related at all.

 

What also don't make much sense to me is that all the other Cisco access points of the same model and firmware that we have placed around the locale don't disconnect like that particular access point that is broadcasting an SSID that the other base stations don't.

So the problem seems to be that particular SSID for some reason.
And like I mentioned, it has been working reliably for six month before the problems started.

alemabrahao
Kind of a big deal
Kind of a big deal

Open a case with Meraki team support.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
redsector
Head in the Cloud

Use an new firmware! I had similary issues.

OK, so you suggest I should dare go for the MR 29.4 Beta? 🙂

Currently on MR 28.71.

cmr
Kind of a big deal
Kind of a big deal

@Tintin did this start happening at about the time you went to 28.7.1?  If so, it could be that the particular AP hasn't applied the firmware properly.  Quickest way to find out is to log a support case showing the event log where all clients are kicked off and then re associate a few minutes or so later.

Tintin
Getting noticed

It did happen before I went to MR 28.71 and that's why I decided to try going to MR 28.71 (not sure what I was on before) since I saw there were some updates concerning MacBooks in the MR 28.71 firmware.

 

I'm thinking it might be worth to try the MR 29.4 beta.

TBHPTL
A model citizen

You haven't really told us much other than your devices disconnect  and that you dont know why the SSID was set for L3 roaming.

 

Definitely open a ticket with Meraki... you are paying for that service. Consider the possibility that the AP is defective.in that one area. Meraki can help you with that.

 

Just some observations from reading through what is above.

 

You have your 5 GHz channel width set to auto. Unless you are in a cornfield in Iowa, all alone, Push that channel width down to 20 MHz wide lots of DFS channels in ETSI domain.... The lower you go on channel width should make your SNR and noise floor more appealing for clients.   Check to see which freq has more issues. 2.4 or 5GHz. Personally I would get rid of the 2.4GHz all together, if you can. The 2.4GHz band is a literal minefield of garbage devices that cause far more issues and help desk tickets then its worth, IMO.

 

If you are doing PSK you can eliminate the  802.11r without much worry. Even in adaptive mode it can cause issues.

 

Intel Macs are way different then M1 based MACs  from a wireless perspective. Also, the roaming threshold for iOS and MacOS devices differ greatly. Also, depending on which version of MacOS you are running, Apple has a really tough time recycling sockets used by anything they didn't publish. i.e. third party extensions, When you run out of sockets, you will not have a good time. You can mitigate this issue  by upgrading  to latest MacOS but i would also tell your Mac users it is a really good idea to properly shut your machine off instead slamming the lid closed and dropping it in their bags. Actually shut it down in the evening and boot fresh daily will make sure the sockets are properly recycled

https://support.apple.com/en-us/HT202628

https://support.apple.com/en-us/HT206207

 

.

Tintin
Getting noticed

Sorry, what do you want to know? 🙂
Not sure what info to provide to isolate the problem more – if I would have known I would have done it.

Thanks for the links to these articles! But the problem also happens on Windows devices.

And the reason for using band-steering and 2.4 GHz was because it was recommended in a Meraki article when more than one SSID was used. I have been using only 5 GHz and the 20 MHz channel too – the disconnects still happened then.

 

Aslo good to know about the difference between M1 based Macs vs Intel ones. But we have several more MR42 base stations that don't give any disconnect trouble, it's only on that particular base station and SSID.

Tintin
Getting noticed

All problems seems to have been solved since updating the access point to firmware MR 29.4.1.

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.
Labels