About HodyCrouch

HodyCrouch · ‎10-09-2019

I don't see the Forget button on my dashboard either. This might be a region-specific feature or related to GDPR compliance. In any case, I believe that setting the group policy to Normal is the closest you can come to removing the client setting unless you have the extra privacy settings enabled in your region. This is just a guess and an area that Meraki support should be able to provide more detail.

HodyCrouch · ‎09-16-2019

I think you want to remove the policy you assigned to the client (with the wrong MAC address). Your screenshot provides a hint with the "only clients with a policy" in the text. For more details, take a look at the following older post. I know it's talking about blocked clients, but you can use the same steps to remove whitelisted clients. https://community.meraki.com/t5/Wireless-LAN/How-to-check-the-blocked-clients-list/m-p/7765

HodyCrouch · ‎09-07-2019

I don’t have anything Meraki-specific to share. If possible, you should test the app upgrade path independent of any MDM solution (rebuilt from a previous version if necessary) and confirm that data is preserved correctly. If you make changes related to how you store data, it can appear that everything got deleted, when your new version is just trying to access the information somewhere else. with that said, I can’t think of any MDM setting that would update an app in place and remove stored user data.

HodyCrouch · ‎08-09-2019

Take a look at this previous topic. https://community.meraki.com/t5/Wireless-LAN/How-to-check-the-blocked-clients-list/m-p/7765

HodyCrouch · ‎08-09-2019

I don't think anyone has mentioned the impact of the "RADIUS Proxy" setting on the Access Control Configuration page. If you do not use RADIUS Proxy, I believe the RADIUS messages will originate from the management interface of each access point. If you do use RADIUS Proxy, the messages will originate from Meraki cloud as indicated on the firewall info page. In one of my networks where I use RADIUS proxy, the firewall info page shows a line for port 1812 where the source IP contains three networks (two /24 and one /20). The destination IP shows the addresses of my two RADIUS servers. When I did the initial setup, I added the three Meraki-provided CIDR ranges as allowed clients in my RADIUS configuration.

HodyCrouch · ‎06-14-2019

I'm not sure what you're trying to test, but you might be able to meet your need using a Meraki Dashboard Live Demo. If you don't already have a demo account, try this link: https://meraki.cisco.com/form/demo With a live demo, you can create new networks in Meraki Dashboard and add whatever hardware you want. It's not a real network, but a fair amount of fake data will appear in dashboard and you will be able to make whatever configuration changes you need. Of course, you can also work with your Meraki sales rep to get a reasonable amount of demo hardware.

HodyCrouch · ‎06-04-2019

The heat map data is not available through any public API. You can use the Location API to receive all location information and use that data to built your own heatmap. Showing locations on a map is relatively simple. Producing your own heat map would take more effort.

HodyCrouch · ‎05-29-2019

The better approach is to have your RADIUS server correctly authenticate users based on the SSID. The SSID is sent to the RADIUS server as the Called-Station-ID. If you can't get your RADIUS server to support this use case, here's an alternate approach. I will admit that this approach is a bit clunky, but you're only trying to make this work for one person. 1. Set the BOSS ssid to use a Splash page and use Meraki authentication. I would also set the captive portal strength to block all access. 2. Create a group policy and set it to bypass the splash page. 3. Assign the new group policy to each device belonging to the boss. I suggest using the per-SSID group policy assignment so that you only assign this policy on the special SSID. Other devices will be able to connect to the BOSS ssid, but they will only get the splash page and they won't have a Meraki user to login. That should be enough to make this work. I guess some people need to be more equal than others.

HodyCrouch · ‎05-24-2019

You're correct that Meraki needs at least three access points to triangulate client location. You will get more reliable location data within the area defined by your set of access points (technically, within the two-dimensional convex hull defined by your access points). Outside of that area, Meraki tries to determine a location, but the results aren't as good as you'll see inside the area. If you want really good location data, you should think about every possible position on your property. At each point, consider four directional quadrants. You want an access point in 3 out of those 4 quadrants within a range of about 3m to 25m (not the exact numbers, just from memory). You won't get a perfect layout, but this is a way to approximate the quality of your plan from a location accuracy perspective.

HodyCrouch · ‎05-13-2019

Be prepared for some pain when you try to keep Facebook login working in a captive portal environment. The web resources accessed by the login pages do change from time to time and you're going to need to keep your walled garden ranges up to date. You will find some resources online to help, but there's no substitute for testing and monitoring. It sounds like you've selected a client-based login flow using Javascript (I'm partially guessing here). If so, reconsider that decision if possible. You're really setting yourself up for a world of future pain. I have found the server-to-server flows to be more stable. You also get a better place to monitor for user issues. You should also be careful about your Facebook application permissions, as they control what data is shared with you. On a related subject, make sure you do some testing with other Facebook accounts. You may find that permissions seem pretty loose when using your own account, if you also created the Facebook application and related tokens yourself. When using other accounts, you often need to go through Facebook's review process to be able to access the data you need. Facebook WiFi provides for a pretty narrow use case. I'm not surprised you've decided to create your own solution. Not sure if that's the information you were looking for. Feel free to ask if you have further questions. I've been spending more time with unique captive portal promotions based on customer behavior rather than on specific social login scenarios. My info may be a little rusty.

HodyCrouch · ‎05-06-2019

This article should clarify what happened when you added the new license and it was spread across all of your devices. https://documentation.meraki.com/zGeneral_Administration/Licensing/Cisco_Meraki_Licensing_Guidelines_and_Limitations/The_Science_Behind_Licensing_Co-Termination

HodyCrouch · ‎04-30-2019

Take a look at Wireless > Access Control (and make sure your guest SSID is selected at the top). Locate the "Captive Portal Strength" setting. If you "Allow non-HTTP traffic prior to sign-on", users will be able to access the internet for most purposes without going through your captive portal page.

HodyCrouch · ‎04-25-2019

This shouldn't be too difficult using the Dashboard API. Start with a call to get the inventory. This will include the serial and networkId for all devices. You will then have to loop through all of the devices and call /networks/{networkId}/devices/{serial}/wireless/radioSettings Each call will return the device serial and rfProfileId. You will be working against the API rate limit, so make sure your script is throttled and that you include some retry logic. You should be able to get through a few thousand access points in less than 5 minutes.

HodyCrouch · ‎04-22-2019

@BretD is correct that you will need help from support to move the licenses. Don't let that stop you from getting the network up and going. There's a grace period to get the license issue solved. When you unclaim devices, there's a period of time before you can claim the device in a different organization. Meraki's documentation suggests around 5-10 minutes. There's really no difference between your 2nd and 3rd scenarios. The steps you follow to move the device around are the same.

HodyCrouch · ‎04-11-2019

I think Sign-on Splash is going to be your best solution. You can configure Sign-on Splash to use your radius server for authentication. This approach provides the same level of flexibility as click-through splash and you can do whatever voucher validation you want. You then send the user to the login url with pre-filled username/password. These values can be one-time use, if you need. Meraki then sends an access-request to your radius server, so you can confirm that the login is valid.

HodyCrouch · ‎04-10-2019

The log entries actually show that the splash page frequency is configured to one hour (3600 seconds). Look at each line that shows a Splash Authentication. As suggested by @kYutobi , you should modify the Splash Page Frequency setting.

HodyCrouch · ‎04-08-2019

Have you considered VLAN tagging? You can set your guest SSID to tag with a different VLAN and use the "different gateway" to provide DHCP. That approach would provide you with the level of control you're looking for over the traffic routing.

HodyCrouch · ‎03-20-2019

You probably already know... Meraki supports both "Click-thru Splash" and "Login Splash" for captive portal. The click-thru doesn't include mauth and doesn't use RADIUS to verify the credentials. Login splash provides a destination URL to authorize the client. With your mobile app and proper walled garden, you don't need to show the captive portal page at all. Instead, have your back-end server call the appropriate Meraki Dashboard API. PUT /networks/[id]/clients/[mac]/splashAuthorizationStatus or PUT /networks/[networkId]/clients/[mac]/policy To use the second option, you would create a group policy that allows the client device to skip the captive portal page. With the first option, the authorization automatically expires. Group policies remain until you remove or change them.

HodyCrouch · ‎03-19-2019

You can use the "Walled Garden" to allow traffic between your mobile application and a back-end system that you control prior to any type of login. Your application would authenticate the user using your back-end system, which would then use Meraki's API to either set the splash authorization for the client or apply a group policy. Note that obtaining the client mac address may be challenging with this approach. You could also provide a special SSID for your application-based connections, use WPA2-Enterprise with RADIUS, and code your application to programmatically connect to the SSID. You would need a custom RADIUS server to authenticate your mobile app users correctly. Generating a user-specific WiFi profile might be another viable option, although I haven't thought through all of the details.

HodyCrouch · ‎03-14-2019

I checked one of my own organizations and I see the same behavior (more jagged lines in the report for Feb 18 - Feb 24). I didn't make any WiFi configuration changes in your two time periods. My guess is that Meraki stores usage data at a high resolution for a limited period of time and keeps lower resolution usage data available for a longer period. It feels like they are using 30 days at the approximate cutoff. In a few quick tests, I found that the summary report showed higher resolution usage data whenever the start date of the report was within the last 30 days. Any older than that and the entire usage data plot showed lower resolution data. Again, just a guess so check it out for yourself and see if you agree.

HodyCrouch · ‎03-07-2019

You should start by logging in to Meraki Dashboard and looking at Help > Firewall Info. That page will show you the required firewall rules to allow Meraki equipment to communicate with the dashboard. With brand new (or factory reset gear), it's generally a good idea to connect them somewhere with DHCP and Internet access to allow the initial configuration to be downloaded. After that, you can do whatever you want.

HodyCrouch · ‎03-04-2019

The devnet sandbox is a good place to start. When you open the sandbox, you should see a username and password that you can use to login to Meraki Dashboard at meraki.cisco.com. You will also see an API key that you can use with the dashboard APIs. Once you login to Meraki Dashboard (using the credentials from the Sandbox page), go to Help > API docs. https://create.meraki.io/ is also a great resource for getting started.

HodyCrouch · ‎02-28-2019

The Dashboard API does not currently allow you to set different policies by SSID for a client (according to the documentation). For a possible workaround, take a look at this thread. I haven't tried this approach myself. You would have to figure out what value corresponds to your group policy. https://community.meraki.com/t5/Wireless-LAN/API-Block-a-device-from-an-SSID/m-p/37958#M5965

HodyCrouch · ‎02-18-2019

Meraki does use standard ports and protocols for cloud management. Some customers have additional communication needs for things like splash pages, RADIUS, Meraki APIs and so-on. If you only need to support cloud management, you can probably use a single set of rules. You might consider contacting Meraki support directly for assistance. They may be able to provide more details.

HodyCrouch · ‎02-18-2019

The exact ranges vary by customer and the specific features being used. From Meraki Dashboard, go to the Help drop-down (top-right) and select "Firewall Info". You will see a list of source, destination, port, port, protocol, direction, and description. This information should allow you to correctly configure your firewall rules.

HodyCrouch

Community Record

Badges