802.11 disassociation issues

[ryu]

Hello,

we got huge wifi issues in our network regarding 802.11 disassociation "events". From time to time we got disassociation "waves" in our network, disrupting the traffic of many devices. As you can image, something like this happen in the work hours, with no indication or sign can be devastating for your work and frustrating for yourself.

We use a MX100, 2x MS210 and 7x MR52.

I contacted the meraki support so many times, actually right know i'm sick of calling the hotline and explaining the support engineer on the other end where hes going to find things in the dashboard / event log. This is not fun. nevermind, this is not going to be a rant.

I havent figured out any reason for the disassociation happening. Its "unknown reason", "unspecified reason" and new this morning " disassociated because client interface was disabled".

This happens on all SSIDs (and all APs) no matter of encryption (we got one with wpa2 psk, one 802x with meraki auth and a open guest network with splash page) and no matter which NIC the device uses (we have the samedell optiplex desktops and latitude notebooks), but there are just random devices affected by the disassociation "waves".

To contain the triggers for this issue, i created a new RF profile in which i forced the ap to use channels in the UNII2 extended range, because UNII1/UNII2 where occupied by other wifis in the area.

I noticed while one of the "waves" happens, the affected APs are stuck in a UNII1 channel which they are not supposed to use.

Someone here who experiences the same problems, or has a idea how to figure out what is cause for this?

[C3SGInc]

Can you describe your physical environment and user environment?  Do you have users moving around allot?  Are the disassociation issues with user byod devices or end-user devices.  Any chance your signals are overlapping too much and causing your devices to hop between AP's?

You might also upload a segment of the messages so we can help look for patterns/issues.

[NolanHerring]

---

@ryu wrote:

I noticed while one of the "waves" happens, the affected APs are stuck in a UNII1 channel which they are not supposed to use.

---

This right here might be your smoking gun.

UNII-1 and UNII-3 (36/40/44/48 - 149/153/157/161) are UNII bands that are NOT affected by DFS events.

UNII-2 and UNII-2e are channels that have to follow strict rules for DFS.  DFS is basically when the AP hear's a radar nearby, it forces the AP to change channels.  When this happens, the only channels that it 'can' go to are the non-DFS channels (UNII-1 and UNII-3).

I would search your event logs and search specifically for DFS events

In addition, search for general channel changes, its possible your access points are simply changing channels often, which can be disruptive to clients.  Event logs will be able to show this easily enough, and you can correlate this with the last known 'wave' that hit you.

I would also ask what firmware version are you running on the wireless access points

Might not hurt to also check the MX and MS, make sure nothing is going on their, maybe they are losing power or something etc.

[NolanHerring]

And if you discover that you are in a 'heavy' DFS area (near an airport for example), the use of DFS might not be reasonable if your getting a bunch of hits everyday.

I personally am OK with one or two channel changes a day, as I feel the gains of all that spectrum make it worth it when in a crowded environment where UNII-1 and UNII-3 are 'busy' already. In your situation, if it is DFS issue, then you might want to update your RF Profile to remove UNII-2 and UNII-2e from AutoRF

[vassallon]

@ryu 

As @NolanHerring said, "I would also ask what firmware version are you running on the wireless access points"

Firmware I have noticed is quite important when trying to troubleshoot disassociation issues.

Also, this is quite important too, "Can you describe your physical environment and user environment?"

Are you in a polluted 2.4 ghz area and you are fighting other wireless in the area? 

[ryu]

Hello,

thank you all for the replys.

First of all, i switched back to the "Basic Indoor" and use the UNII1 band.

Firmware on MR 26.6.1

Firmware on MS 11.31

Firmware on MX 14.40

@NolanHerring I changed to the UNII2 Channels just because the issues happened also on UNII1 (With the Basic Indoor RF Profile).

@vassallon Not really "heavy", a lot of 2,4Ghz wifis with maximum -68 dBm. A few 5Ghz wifis mostly using UNII1 band.

We got a office in the 3rd floor (highest building nearby), split into two areas. One work are and on the other side of the building on showroom/conference room area. In the Office is the MX100, a MS210 and 4 MR52. In the Showroom is one MS210 and 3 MR52. The Switches are connected over Fiber Optic Cables.

On a normal day there will be ~70 clients on the whole network, a few devices using cable but the most connected over wifi (Desktop Workstations also connected over wifi, because of the poor cabling in the building.

The office is 10 to 50 meters, zoned with drywalls. The wifi coverage is ok, from -39 dBm to -49 dBm in the workspaces and up to -65 dBm in unused areas.

The issues happens on all devices, no matter if they stay stationary or moving.

The last DFS event i found in the log and the RF page from the AP which has detected it.

Feb 20 11:08:44	AP Training Room			DFS event detected	channel: 112, radio: 1
Feb 20 11:26:43	AP Training Room			Auto RF channel change	Channel changed to improve network performance  « hide New_Channel 108/80 Old_Channel 48/80 Radio 1
Feb 20 11:36:14	AP Training Room			Auto RF channel change	Channel changed to improve network performance  « hide New_Channel 100/80 Old_Channel 48/80 Radio 1
Feb 20 18:13:28	AP Training Room			DFS event detected	channel: 100, radio: 1
Feb 20 18:22:59	AP Training Room			Auto RF channel change	Channel changed to improve network performance  « hide New_Channel 100/80 Old_Channel 48/80 Radio 1
Feb 20 18:38:48	AP Training Room			Auto RF channel change	Channel changed to improve network performance  « hide New_Channel 112/80 Old_Channel 48/80 Radio 1

*edit link to screenshot

[NolanHerring]

to me it looks like fairly frequent channel changes

You might want to try statically configuring each AP on a unique channel (you'll need to verify which channel is best for each AP given its neighboring networks etc.) and try to use only UNII-1 and UNII-3. Make your SSID 5GHz only if you can. Those signals you mentioned are not just 'ok', they are as good as it gets lol. very strong. not sure where your power levels are resting, assuming your using the AutoRF for power as well? I usually recommend reigning in the min/max on the RF Profile, but this requires you to know what ranges to use, given the survey that was done (if there was etc.).

[vassallon]

@NolanHerring 

I also noticed that @ryu is using 80 MHz channels, what is your thinking on using those?

I would think going to 40 would likely improve performance as well as there would be less channel hopping and more channels available for use.

[NolanHerring]

Good catch !

I was tunnel visioned on the channels lol

DO NOT use 80MHz is my recommendation. If you 'can' get away with 40MHz sure, otherwise I would default to 20MHz. There is no where near enough spectrum to pull off 80MHz in a 'normal' enterprise environment.

[ryu]

@NolanHerring @vassallon Thank you very much for the help. I followed your advice's and going to observe if this will finally remove the issue.

[ryu]

A little update:

Right now everything is fine, no disconnections or greater issues. @Nolan, @vassallon thank you both very much for the information and help.

[NolanHerring]

Glad to hear @ryu !

[vassallon]

@ryu 

Glad we were able to get things stable for you. 

[Cabimas66]

Hello Ryu,

I was reading your posts from 2020.

Did you solve the issue when you removed 80Mhz channels?

I have a customer with so many 802.11 disasociation, including from static printers

Thanks for your help

Enrique

[jpitt2k2]

2023-  I just had a similar issue. -  The SSID had the setting mandatory DHCP enabled.- After setting Mandatory DHCP to disabled the clients worked as expected without issues. 

The real issue was that Meraki Dashboard does not have an information bubble explanation next to this setting - as they do on almost all other settings that can be changed.  Even Worse the Dashboard logging made it look like the devices were talking to AP's and connected without issues, even though they were not connected, and all users were not talking on the actual network.  I was relying on the dashboard to report errors on clients but it had none.  Hopefully this helps someone in future.