I have been using a Meraki Go GX20 for a couple of months now and it seems to be working well.
However, the "Reboot hardware" just does not work from the app. I have tried many things: reset hardware, uninstall/reinstall app, tried using app from different device, so on. Nothing fixes the problem. All I see is a kind of rotating beach ball and it never changes from that.
I have already been in contact with Meraki Support and they have run out of ideas.
Wifi on my home network is provided by a Ubiquiti AmpliFi in bridge mode. The GX20 provides the security to the internet. Other than the problem above, everything works great.
Has anyone had a similar problem? If so, how did you fix it please?
That is certainly an interesting dilemma. Testing this out personally, I see the GX20 lights go out moments after issuing the command to reboot. I even tested with a VPN to simulate my connection from multiple regions throughout the world, to be sure.
The reboot command is effectively web traffic that is secured. Are you behind a splash page on your network, or somehow have network traffic restricted when using the Meraki Go app?
The rotating beach ball is the request sent to reboot waiting for the confirmation that the command was received. It seems like the command isn't reaching us.
Thank you for the reply.
No, there is no splash page on the network and no network restrictions. The other two options: Test Connection and Blink LED work just fine.
I even swapped out the AmpliFi for an old Apple Airport Extreme (also in bridge mode). Exactly the same result as before. I just wonder if bridge mode would be the cause of the problem.
Thank you for your reply.
I tried a few other things.
First I moved the GX20 to be behind the AmpliFi. So, the AmpliFi was the internet gateway. The Meraki Go app could see the GX20 on the network.
Result: Still no reboot.
Conclusion: Bridge mode is not the issue.
Second, my ISP provides some filtering capability that can be configured on the web. None of that appears to block Cisco traffic, but I temporarily disabled the filtering completely.
Result: Still no reboot.
Conclusion: ISP filtering is not the issue. However, I have contacted my ISP to check if any web sites or ports are blocked globally on their side.
Third, I notice that in the app there is Hostname assigned. It looks like this format:
<organization name>-appliance-<some kind of random characters>.dynamic-m.com
I assume this is to handle Dynamic IPs.
Trying to get to his web site fails. Correction: It loads the GX20 configuration page.
Not sure if I am meant to see the contents of this hyperlink. Correction: It loads the GX20 configuration page.
That hostname is indeed intended to help with dynamic IPs and port forwarding rules.
When you load the GX20 local status configuration page there, does it report any connectivity errors on ports UDP 7751 or something along those lines?
The code that handles this reboot and the software in the app that sends that command is being used quite widely. The only valid conclusion I can draw is the packet carrying the reboot command is not reaching the Cisco Meraki cloud servers, which would then send it on it's way to the GX20.
Have you opened a support case regarding this behavior? There are multiple cloud servers handling commands and configuration updates from the app that then reach the equipment. Perhaps you are facing a specific problem that others cannot reproduce for that reason.
Thank you for your message.
No connection errors reported. Device reports all is well and healthy.
I have been in contact with support, even to the point where support remotely rebooted the GX20 a few days ago. Successful, but spooky!
The issue is still with support.
That is simply a head scratcher... I'll touch. base with them lol, no promises on what I'll come up with.
I owe everybody an update on this one.
Given support and myself don't have any way to see in this tunnel, we're working on building a proper light.
The main issue we face is not being able to reproduce the issue ourselves. This is further complicated by the data that would help us not being saved or being accessible to end users.
As such, we're working on a bug reporting tool in the app that will help give us contextual data surrounding the failure you are facing (and other failures, too) as they occur. Our goal is to fire a dialogue when unexpected actions like this take place, allowing you and others to submit error reports with the ever so necessary details about that problem.
I'll provide an update here after we make any changes in how reboot commands are handled.
Quick bump - our next app release will have an additional success check on the reboot command.
It won't solve the problem by any means, but it will certainly take us a step in the right direction.