Wi-Fi Clients being Disassociated due to "excess frame loss"

[OilG]

For several months now, our customer has reported poor Wi-Fi network performance from their Meraki Wi-Fi network.

One of our immediate observations is that Wi-Fi clients on the network - using Meraki MR46 APs running firmware MR 29.4.1 - are frequently being disconnected from the Wi-Fi network (several SSIDs) through 802.11 Disassociation; and in each case this is being caused by one several different factors, the most significant of which is reported in the Event Log for Access Points with the Details: “excess frame loss”.

1. What percentage or rate of 802.11 frame loss is sufficient to cause the Meraki access point to disassociate a client?
   
   
2. How can we adjust that percentage threshold, or frame loss rate threshold, or the timespan over which that percentage/rate is assessed - so that clients will then not be disassociated as often as they are currently being?
   
   
3. How can I see the actual percentages of frame loss / frame error rates:
   
   
1. For each client?
2. For each AP?
3. For the customer's network as a whole?

Many thanks,

Ian

[daryllhorner]

Mario, in our experience, client balancing on resulted in very erratic behaviour and clients roaming unnecessarily, and to very poor choice APs. But not disconnecting as per 1st issue where we see excess frame loss, dhcp detection and deauth generally

We are rolling back to 28.7 now, will update late tomorrow on how it has gone

In honesty, 28.7 networks I've seen some excess frame errors, but users do move around. Compared to 28.5.1 where I barely saw any, but it's difficult to see the forest for the trees. It's a real event log as far as I see it can genuinely happen if a client moves to a poor signal area, so have to use some interpretation

Network we (IT) are on is currently processing 28.7, and we should have a yes/no it fixed it or not by late afternoon tomorrow

[Eric Boers]

Hi All,

I've read all the discussions and i saw exactly the same disconnection issues with 29.4.1 on bridged and guest ssid.
We're using MR44 and MR76's in a large environment and only using 5Ghz. I see laptop devices with a static positition and a very good connection SNR around 38 and 50 dB dropping suddenly traffic all the time.

Because of that i updated the Meraki firmware 2 weeks ago with version 29.5.1
In the beginning it seemed that the update works, but now after 2 weeks the users complaining again and see many excess frame loss with all different device vendors.
I am curious to see the results from you guys downgraded firmware with version 28.7 after 2 weeks testing.

[ajamua]

A week ago we upgraded to 29.5.1 but last week we had a low number of users come into the office and experienced none of the sudden traffic drops but still saw the excess frame loss messages in the event logs. I suspect this week might have more traffic and I can determine the affect of the upgrade but I am not feeling hopeful.

[ajamua]

Upgrading to 29.5.1 did not resolve the issue. I feel that whatever this issue is it started with 29.4 though I never really upgraded to this and went from 29.8.7 to 29.5. At the time I was trying to fix issues I was having with layer 3 roaming so I was not thinking about this issue specifically. When layer 3 roaming still seemed to be a problem I removed it from my environment completely. That's when I started noticing the issue that was probably already there hiding behind my hatred of layer 3 roaming.

I am thinking of returning to 28.7.1 now. I really feel this has something to due with the new Client Balancing feature that was launched with 29.1. I upgraded off 28.7.1 because I thought that layer 3 roaming might improve so now that it is removed maybe it will stabilize the issue. What I do not understand is why Meraki refuses to admit this is a real issue.

[IsmaelRomero9462]

Check DFS events.

If your channels are not set to auto, check to see if the AP's are operating on the channels they are actually set to work.

MR46 has a "known bug" where AP's changing channels due to DFS don't return to the original channel therefore they may cause co channel interference.

We are dealing with the same problem and waiting for Meraki go fix the bug. Rebooting the AP corrects the problem.

[ajamua]

can you elaborate more about what you are seeing with DFS events? were you able to capture any of this in monitor mode? I always see some DFS event being right next to a large river but I am not certain of the affects on users. are you using auto channel or static? my understanding is that auto channel rules should apply after the DFS event.

[IsmaelRomero9462]

I did a packet capture once only when a client reported login problems at a particular spot in the building which sounded unusual to us.

There I noticed that the device was trying to link to an AP working on a channel we never use (153). We need all the channels there are due to high density, but 153 and 149 are used by apple tvs so we avoid them. We have lots of Apple TVs in a school setting.

To check DFS events you can go to meraki dashboard, Network-wide, Event log, Event type (include). There you filter out the event-type you need (DFS). A problem that can happen here is that if the event happened too long ago, then the history will return nothing. But the catch is if you compare what channel the AP is actually working on versus the channel you have set it if you have set it manually. You can open two pages, one with the APs that includes the Channels Column and the other with the channel settings and look for mismatches. By the way, I use the old version. Our engineer is preparing a script to do it automatically but has found some limitations with Meraki API at this point.

[ajamua]

We finally pulled the trigger and asked Meraki to roll us back to 28.7.1. Now we sit and wait. Today is one of the busier says of the week with people moving for meeting room to meeting room so lots of roaming and chances to end up in excess frame loss wormhole.

[MarioFishery]

Let us know how 28.7.1 goes for you. We are still on 29.5.1 and have MR 33,MR 36, MR 46, MR 55, MR 56, MR 86 on our network. With turning off Client balancing things have been a bit stable BUT still few users complaint of disconnections. Apple TV still facing issues in some areas but still not consistent. Looking forward to your feedback on 28.7.1

[Bharadwaj GK]

Did the rollback help and are client getting associated faster now? Pls let us know.

[ajamua]

I feel like rolling back to MR28.7.1 was successful but need to monitor some more. Today was not as populated as last week but enough to say that we did not have any user go into the excess frame loss sunken place. I also stopped getting some awful association issues with the phones on the network. I still see the excess frame loss messages in event logs but like I stated before this is not an indication that there was an issue. Overall I am seeing way less disassociations due to excess frame loss. If you want to roll back to this version you will need to call in to the TAC and have them schedule it. I would say read the release notes first. I upgraded from MR28.7.1 to avoid layer 3 issues with sticky anchors so I felt confident with the downgrade since I removed layer 3 routing from my environment. Good luck!

[Abdulaziz Loonat]

are Meraki actually aware of this issue with the current firmware (as people who roll back and commenting issues seems to be resolved). Are they releasing a new firmware to resolve this

I have logged a case with Meraki and pointed to this thread

[MarioFishery]

Our issue only seems to be with Apple TV's disconnecting. Rest all seems fine for us after turning off clint balancing

[MarioFishery]

We enabled all services on Bonjour forwarding Bridge mode and layer 3 roaming only. We had restricted it only to AirPlay and Apple TV's seems to be working fine now on the latest OS 29.5.1.

Client balancing is still Turned off.

[smartinez790]

Also experiencing this with MR57s. Worked with support and got a ton of packet captures but no help from Meraki.

We are rolling back to 28.7.1 this weekend. I updated our case with a link to this thread with the hope that it gets some attention from the Meraki team.