MR33 - Failed connections

Getting noticed

MR33 - Failed connections

Had an interesting issue today. Some windows 10 clients were unable to get an IP address. Didn't matter whether it was a corp or guest SSID. First I blamed Windows 10 but I tried going to a different building and in that building the client worked fine on both SSID's. Back at my desk it would fail and colleagues around me also had the same issues. The windows 7 device on my desk would work fine.


I looked in wireless health, failed connections and noticed that all the failed connections were on 1 particular AP. So I rebooted it and then all was ok again.


We've only been using these MR33's for a few weeks. Has anyone experienced something like this before?

12 Replies 12
Kind of a big deal
Kind of a big deal

@superfly  Yes thats technology for you, I have seen this exact same issue with multiple vendors, no idea what causes it and it usually only affects new connections, existing connections seem to be OK. 


I find this usually happens once in a blue moon but if you are seeing the same access point have the same issue more often I would open a support case. 

I've ran into similar instances, reboot always fixes it. I've attempted to go out of my way to collect packet captures and open support cases but they never actually determine the root cause and end up suggesting I upgrade firmware to a beta build which kind of kills me inside. So I reboot my access points on a scheduled basis to keep them running fresh.
Nolan Herring |

I've seen this before also and don't have or know of a root cause yet.  True that it seems to be random and not that frequent, and that a reboot seems to fix it, but nonetheless I'd suggest opening a Support ticket if/when you catch this issue in progress.  If nothing else it'll allow Support to do a little data collection prior to any AP reboot (if you can afford the extra few minutes) since that can only help them get closer to a root cause, and/or identify a specific hardware/firmware combination where this occasionally happens.


@NolanHerring how are you rebooting on a schedule? if this just a manual operation or you have a automatic way of doing this?


I was wondering if scheduling the ssid availability to go off for 30mins in early morning would have close the same effect

it would not reboot the AP but it would clear all associations which is what I was wondering if I could get away with




Kind of a big deal

I use a python script we wrote, with stackstorm, and it runs it once a week and using the Meraki API to reboot devices. It pulls entire inventory, and reboots only MR device types.

Nolan Herring |

is it possible for you to share it with me or a cut down example

when it comes to scripts and APIs its not something I do so its learning curve to get correct

just to carry on this


I have a nice restart script now so all I have to do is tag my AP's with 'nightly-reboot' and they start rebooting with a 40sec delay between each


but my next question is in the event logs there is no confirmation or reboot acknowledgement 


not just for the script but if I do a manual reboot there also does not show in the logs which is a bit of a pain


as a Helpdesk informed me they have been rebooting an AP constantly throughout the day but not telling me and there does not seem to be any logs to confirm this


is there a way I could capture it as an event?



Head in the Cloud

Isn´t it easier to use the scheduling of the switch port. Halve an hour a day scheduling as off, and after the time is run then the accesspoint reboots. It an easy way without any scripts.

You find it on "switch" - "port schedules".


Kind of a big deal

@superfly wrote:


I looked in wireless health, failed connections and noticed that all the failed connections were on 1 particular AP. So I rebooted it and then all was ok again.


This has become almost always the first place I go when I start troubleshooting "The WiFi sucks" issues. It's made my life easy numerous times now. Great tool. 

Agree @jdsilva, Wireless Health is a fantastic assurance tool, and a great example of Meraki deploying a powerful new feature that was driven by customer wishes, didn't cost anything, didn't require any licensing, and typically didn't even require any firmware updates or AP reboots.  And it's even got a full API behind it for automation, alerting and other cool stuff.  I've heard this from so many customers, that Wireless Health is the first place they go now when there's an issue.

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.