WiFi devices disconnecting all the time

Adonistm
New here

WiFi devices disconnecting all the time

Hi there,

 

We are having issues with our wifi that people complain it's dropping all the time. To give you a quick overview of our environment we have 7 access points broadcasting 2 SSID. One of the SSID is using RADIUS authentication and the other just WPA2-PSK for guests. The issue is happening with both SSIDs. In the event log I can see a lot of messages like:

- 802.11 disassociation unknown reason

- WPA deauthentication

Many occurrences from same devices in a minute. The SSID using RADIUS authentication uses only 5 GHz and the Guest one uses both. I disabled 802.11b devices and enabled 802.11r to see if that would help but nothing so far.

Any ideas of what could be causing this issue and any suggestions to improve/fix this ?

 

Thanks

 

Selection_080.png
Selection_081.pngSelection_082.png

 

 

17 Replies 17
randhall
Getting noticed

Look at Wireless> RF spectrum on those APs and look for interference (hotspot, wifi-direct enabled printer, etc)

PhilipDAth
Kind of a big deal
Kind of a big deal

The 2.4Ghz spectrum is a bit congested.  Are you able to disable this and only use the 5Ghz spectrum?

Adonistm
New here

I've checked that and there's very few to none hotspots. Usually only when someone is testing something from their phones or whatever. Printers are all wired and have wifi disabled and wifi-direct disabled as well. I will check for more things that could be interfering.

I'll try to disable 2.4 since it's enable only for legacy devices but all devices now should be able to take 5Ghz. Let's see how it goes.

Thanks!

MarcP
Kind of a big deal

I´m having the exact same problem now...

 

But instead of having the problem on all SSIDs it is only on the Guest WiFi. doesen´t matter if it is a iOS or Android device.

 

2019-04-10 10_30_26-Event log - Meraki Dashboard.png

GIdenJoe
Kind of a big deal
Kind of a big deal

Are you sure the disasociation frames are coming from the AP's and not some other network device sending disassociate frames on their behalf like air marshal going haywire?

Maybe protected management frames can help in that case. 802.11w

MarcP
Kind of a big deal


@GIdenJoe wrote:

Are you sure the disasociation frames are coming from the AP's and not some other network device sending disassociate frames on their behalf like air marshal going haywire?

Maybe protected management frames can help in that case. 802.11w


You mean mine?

 

Mine is solved, it was just a setting for reauth every hour... 😞 emberassing 😄

GIdenJoe
Kind of a big deal
Kind of a big deal

Nope MarcP, I was talking about the thread starter. But indeed your log messages seem to state a reason (auth expired), nothing embarrassing about that. Mistakes do happen the first time around 😉

I meant the unknown reason disassocs from the threadstarter.
RyanG22
Conversationalist

I'm also having this issue on site, which has been happening now I believe for a couple of months but appears to be getting worse.  Still yet to figure out if the "wireless issues" I'm seeing are all the same problem, but also what the cause could be.  It used to be I could reboot a particular AP and the user's device would move elsewhere and start working.  But not a 100% working workaround and things are getting more frequent and widespread.

 

If interference is a possibility - what can we do to identify that and resolve I wonder?

GIdenJoe
Kind of a big deal
Kind of a big deal

- Interference is caused by other AP's or clients associated to other AP's on the same channel. They cause performance issues but that would need to be extremely severe before clients would start dropping their association.
- Higher noise caused by non-wifi devices can cause the SNR to drop and clients to go below a certain PHY rate and if you've configured a minimum PHY rate they could be dropped because of that.
- But it could be a driver issue on some clients since a certain update.

Basically you'll need to find out if where it happens (if it's everywhere then test it anywhere) and if it's a certain device type, then test with multiple devices at that location to gather your info (PHY rates, retry rates, dropping)

- If it's a driver issue then update/downgrade, if it's a noise/interference problem then you'll need to do a troubleshooting site survey at that location (spectrum analysis for noise, and passive survey for signals and interference)
MMoss
Building a reputation

Are they all MR18's you are having problems with?

What Firmware are you using? I put the Beta Version 26.XX to try and fix a different issue on my MR 32's and caused a similar problem. Did something to the DHCP and it wasn't renewing the leases I believe. I just rolled it back, no troubleshooting

Asavoy
Building a reputation

@MMoss I discovered this issue quite some time ago on the 25.x firmware for the MR34.  Essentially, the SSID that uses Local LAN for client assignment would not complete DHCP requests properly, while the SSID that uses Meraki DHCP had no problems.  I ended up forcing Meraki to downgrade me to a 24.x firmware until they could implement a fix, even though that firmware had major issues with 2.4ghz band. 

 

The 26.2 firmware has been mostly stable for me on all MR34/MR42/MR52 across my sites.  Any AP that I've found to be problematic has been removed from the network dashboard, hardware reset, and then reintroduced to a network.

 

(edited to change MR32 to MR34)

MMoss
Building a reputation

@Asavoy 

 

That's pretty interesting. We ran into a similar issue even on the version 26 beta. I'll look into it more when I get in tomorrow. Do you have a link to the notes you were looking over or know which set of patch notes it was in?

Asavoy
Building a reputation

@MMoss  (I realize I erred in saying MR32 in my previous response, as it was actually MR34)

 

The earliest one I found was from 25.1 "Condition under investigation prevents DHCP offers from being sent over the air (MR34)"  This was right at the beginning of my school year and teachers were freaking out.  I was able to get with support and engineering so they could gather info while it was happening.  That Known Issue dissappeared in 25.5 without showing up in the Bug Fix section.  However, I stuck with a 24.x firmware until just recently.  I could deal with the abysmal throughtput on 2.4GHz way more than having to reboot 104 WAPs over 3 different sites practically daily.

 

I recently had a couple random MR34 issues on 26.2, but I chalk that up to 'ghosts' in the firmware upgrade process.  A couple randomly didn't come online properly, while a couple weren't allowing connections.  For that I used the remove/reset/reassign trick.

vassallon
Kind of a big deal

@Asavoy Good to hear that the MR34 seem to be playing nice with 26.2. We have some issues with the MR34 that we are hoping are fixed with that release of firmware. 

Found this helpful? Give me some Kudos! (click on the little up-arrow below)
MMoss
Building a reputation

@Asavoy 

 

I'l still check it out, rarely does one bug seem to limit itself to one set of hardware.

RyanG22
Conversationalist

My issue is on ~13 MR18's, all on 25.13.  No other WAPs on the network (although plenty of others in the building polluting the air).  Hopeful that maybe a firmware update is out there - is there a way to force the beta on, or is that not a great idea with outstanding bugs?

 

Has been quiet due to Easter, so not sure how the issues are right now - I changed a few settings last week out of desperation. 

dalmiroy2k
Getting noticed

If some of the APs in your network are third-party (Non Meraki) that may be the problem. 

 

Go to Wireless --> Air Marshall and check the following:

 

"Allow clients to connect to rogue SSIDs by default" is selected

 

111111.jpg

Check the Rogue SSIDs tab, it may have banned some of your Non-Meraki Mac address or SSIDs. 

 

222222222.jpg

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