I am seeing continuous disassociation/association and deauthentication/authentication happening on one of my MR32 APs. Can anyone offer advice?
The example below is a RaspberryPi device, but I also see it on a Windows 10 laptop
Firstly; Do you have DFS channels enabled for your wireless environment? - https://documentation.meraki.com/MR/Radio_Settings/Dynamic_Frequency_Selection_(DFS)
Check to see whether the AP in question is reporting DFS events which would cause all clients to disassociate/re-associate to the SSID as the channels change. If this is the cause, exclude DFS channels from your wireless environment.
Tell me how this goes; If you're still having issues after this we may have to look at the RSSI for these clients/configuration of the SSID.
I have 2 Meraki APs advertising the same SSID, but they should work in conjunction as a mesh, right?
Not necessarily. Depends on how you have it set up how gracefully the clients roam.
This could be a number of things, but if it is only affecting 2 devices I would look at those first, specifically the radios on those devices and their compatibility with the SSID configuration/authentication mechanisms you have used. Update the drivers if possible.
Is this issue occurring only on this particular AP? Do the devices connect fine to other APs in another location?
I had a similar issue, but with chromebooks, and I couldn't figure out what was going on.
What I did was change the radio settings on the SSID from 5Ghz only to Dual band with band steering, and for some reason that seemed to fix the problem. All of a sudden the chromebooks were able to see the SSID and connect, so something you could try on your SSID that is giving you trouble.
RSSI looks pretty good, so I don't think weak signal is to blame here. What does the RF environment look like? Is it congested? Looking at the logs, the client connects incredibly briefly then disconnects. Any kind of splash page, radius, or anything else like that set up that is preventing it from staying connected?
Edit: Just realized all the times are almost the same, every day. What is occurring at around 2:00 CDT? Something around that timeframe is causing loss of connectivity.
What is occurring at around 2:00 CDT?
I was thrown off by the word "constant"...It looks like this only happens once a day at 02:00. What prompted you to look at this? I'm going to guess that this once-per-day disassociation is probably not the cause of the problem you're investigating. Just a rabbit trail...
I didn't actually realize when I posted this that the issue was happening on separate days - I was only looking at the time. I see this happening often across different devices - a better example would be here, on a Windows 10 laptop:
"unspecified reason" coupled with frequent associate/disassociate may be interference. Perhaps a helpful person has introduced a new device or turned on their phone hotspot. Check out that AP in RF Overview. Here's an example of a helpful person at my site. Super helpful, actually, stomping over a large swath of airspace with an 80MHz channel.
Here, too, I go through this. There is no explanation or solution to this case.
I have already contacted the manufacturer and supplier and if there is no solution we will exchange the solution.
Because that way it does not work.
Did you find any solution out there?
Can you please post a screenshot of what you see on Wireless > Air Marshal?
Please also check if you see many DFS events on Network-wide > Event log (You can filter it here)
These messages are usually sent from the device to tell the AP that it is leaving the AP (for example, when it is changing to another SSID, or simply losing coverage)
This is the screen of my AirMarshal.
I receive yes emails from Rogue Ap in which Meraki himself makes this block and I enable the keywords to put keywords.
But I keep looking around the available networks thinking about this, but I find nothing. And Meraki can not be so sensitive this way these days, right? Each block has 50 networks available and if you think the world could only exist Meraki.
And this problem though that is more often when roaming it also happens when I am sitting at my desk. I will get my smartphone to make a VOIP connection and I find that I am without a network. Actually this is extremely frustrating I was expecting too much from Meraki, but it's not working.
As I said above, I'm already talking to the supplier, because I have no outputs.
@Pedro from my personal point of view this can be looked more into with a monitor mode packet capture.
It's very unfortunate that you've had a bad experience with our devices, but, what I can offer you, is that if you send me a private message with the case number you opened so I can look more into this.
I would like your technical opinion and experience that you already have with Meraki.
I own 5 SSIDs:
Vlan default = SSID 1
Vlan 2 = SSID 2
Vlan 3 = SSID 3
Vlan 4 = SSID 4
Vlan 5 = SSID 5 (hidden)
Only one of these Vlans I use the DHCP Meraki, in which I use for visitors with registration in the meraki portal and authentication by splash page. And this SSID I do not have to worry about roaming.
In Vlan 4 it's where roaming would have to work and it's causing me the biggest problem. This network is separate and specific for smartphones because we are users of VOIP (SIP). And users move quite a bit here being a very large company in terms of m / 2.
The image below will be in Portuguese because I am from Brazil the error is this:
When he accuses this error are those logs that I have sent there are some previous answers about disassociation errors.
My swtichs are branded Dell all with Vlan tags between Vlan default and Vlan 4. Communication works perfectly, IP addressing, etc...
The same problem is the scrolling and the reason for this authentication error.
When that happens we are at least a 5 minutes without connection, the smartphone gets lost does not know what it does. After long minutes he can connect, but always deactivating and activating the device wifi.
I already read about the Meraki guaranteeing better performance with 3 SSIDs using group polices, okay. But is it allowed to create 11 SSIDs by which they indicate use only 3? It would buy a ferrari and ride only 100km / h instead of 400km / h. Anyway, what I just did at that moment is:
Excludes Vlan 4 (smartphones). I put all my smartphones in Vlan default SSID 1 and made group rules polices for network security not to have total TCP communication with my LAN.
I own that now.
Vlan default = SSID 1
Vlan 2 = SSID 2
Vlan 3 = SSID 3
Vlan 5 = SSID 5 (hidden)
This Vlan 5 would only be for management devices in which I am already thinking about creating a new polices group for them and joining everyone in the default Vlan and thus eliminating Vlan 5. So I would abide by the Meraki documentation using 3 SSIDs on the maximum.
And after all this if the problem continues?
Do you think I'm making a mistake in everything I've just documented?
Once you go over 4 SSID's a large amount of airtime is consumed with 802.11 beacons announcing the SSIDs. This is nothing to do with Meraki. It is a general 802.11 issue.
Have you got 802.11r roaming enabled on the SSID? You should.
It is enabled because I own some Iphones, Samsung A2017 and S8.
But the biggest focus would be the Samsung A2015 in which the native 802.r feature does not seem to me to be a pity.
Another point I'm not so fond of using group polices is that I'm forced to use the dual band because as I will have several types of devices, some will not have the 5ghz available. And the devices that are already 5ghz run the risk of staying in the 2.4ghz channel. Would you have any other solution also for this model?
@Pedro I think the best way to go would be to give us a call, but basically, what I can point is this documentation about troubleshooting VoIP deployments.
We enable the user to have more than 3 SSID because there are some cases where you would like to enable some SSIDs on especific APs (and not in others, i.e. Meeting Room XYZ), so this way you can creater them.
I would also like to point that usually these kind of scenarios are complicated in the sense that it is not only one problem, if not more than one, and dividing the big issues into multiple ones is quicker. For the roaming issue, I would take monitor mode PCAPs on the wireless (at the source AP and at the destination AP), as well as PCAPs on the wired side of the APs.
There must be a reason why the device is having issues doing the roaming and usually in the reassociation response frames you can see what was the reason.
I'd like to know if I should worry about these types of events below desassociation.
As I'm reading a lot of logs this is making me confused. Should I consider them as problem? I do not need to worry because it can be something normal?
Because they are users who walk all over the company, see that they travel in several APs during the day. That's why sometimes I get confused by these desassociation events.
As of today 12/13/2017 I have only 3 SSIDs in each Vlan and I have created group rules polices allow / deny.
Is that the right concept?
I'll monitor and cheer here.
It really depends on your implementation. Those messages are basically the STAs leaving the AP without sending a disassociation message first, or the AP not being able to hear it.
Said that, it's not like they are occurring several times a minute, so I wouldn't worry about them, as some devices do not send any disassociation message before leaving the AP or turning off its wireless LAN radios,
@alyssafriesen on the other hand, I see yours are also separated by days, so there shouldn't be anything to worry about. The device seems to be leaving the AP (maybe because it is a saver power mode specific to this device).
After doing the reimplatação of the network using group polices instead of Vlan and other SSIDs I can affirm that the wireless network has changed totally. In 48 hours I did not have a fall, I did not have any type of interference and all my VOIP connections normalized, without ropes, without robotic voice and loss of connection.
Roaming is also a service that has stabilized, I do not have drops from one AP to another.
Actually what works in Meraki is the polices group rules and honestly it gets easier to manage, more secure and controlled.
I can say that I am happy at the moment and I will have a satisfied new year! lol
Many thanks to all for your patience and understanding.
Thank you very much
I myself have been experiencing this issue on my network.
This are the things that worked for us, we first checked the signal strength of the channels affected. We determined that there was a range of 3dB - 6dB very low. We changed the channels and within minutes the signal on the clients increased significantly to a 20dB.
I would suggest checking your signal and channels. I realized that in this AP auto channel selection is not working. It seems like I have to be switching channels constantly myself. Today I found out that the AP was located next to two glass windows. I suspect this is the root cause
I hope it helps.