About HodyCrouch

HodyCrouch

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

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

The API does not appear to support setting different group policies for a client by SSID. I'm not aware of any workaround.

HodyCrouch

Your idea that Meraki keeps the OS information when a device previously connected to the network sounds reasonable. I doubt that Meraki would make that information available across organizations, but there's no way to know for sure without either testing yourself or getting Meraki to tell you.

HodyCrouch

I did a quick scan of some data from the Scanning API in a couple of environments. I only see a value for OS when the device is connected to the network. I've never seen details from Meraki on how they identify the OS. I would guess that they are using fingerprints of certain network traffic, similar to remote OS detection in nmap. Meraki appears to keep its own database when people flag the device type as inaccurate in Meraki Dashboard. If this guess is accurate, a device would have to associate to the network prior to OS detection. The results of OS detection may be inaccurate, especially when new devices, drivers, and OS versions are released. There's a decent chance that similar technology is used for detecting rouge access points on the LAN.

HodyCrouch

You can create a group policy that bypasses the splash page and then apply that group policy to any user you want to be connected for more than 3 months. If you want to automate the solution, you have a couple of options. You can host your own splash page and make an API call into Meraki to apply the group policy after the user clicks through your splash page. You can also use MAC-based access control with a RADIUS server and set the group policy in the RADIUS reply. You might also want to open a case with Meraki to see if they have any other configuration options available to you.

HodyCrouch

You probably already considered this, but I wanted to make sure. In most environments I set up that require some type of sign-in through a splash page, we configure a walled garden. This allows the device to navigate around the splash page, view T&Cs, and sometimes access promotional content prior to completing the sign-in/splash process. You then set up the splash interval to something that you would expect. Sometimes hours, sometimes days, sometimes longer. Depends on the goals and the customer.

HodyCrouch

A quick and dirty approach is to create a Group Policy that does not require a splash page. After the user signs in, you can use the Dashboard API to apply that group policy to their device. At some future point, you can remove the group policy from their device, which will cause the splash page to appear again. As Philip suggests, you can get more control using Sign-On splash with RADIUS, interim updates, and CoA disconnects. See https://documentation.meraki.com/MR/Splash_Page/Interim_Updates_for_Splash_Sign-on Hosting your own RADIUS server gives you a lot more control.

HodyCrouch

The endpoint /networks/[networkId]/clients/[id_or_mac_or_ip]/events includes parameters for startingAfter and endingBefore. The documentation warns against client applications setting these parameters. When you make a request to this API, the response includes a Link header. For example: Link: <https://n000.meraki.com/api/v0/networks/N_1234567890/clients/abc12345/events?startingAfter=1476908909.0>; rel=first, <https://n000.meraki.com/api/v0/networks/N_1234567890/clients/abc12345/events?startingAfter=1517256994.237001>; rel=next, <https://n000.meraki.com/api/v0/networks/N_1234567890/clients/abc12345/events?endingBefore=1548874564.0>; rel=last You can use the values of startingAfter or endingBefore in the Link header to work your way through all events for a given client. If you want to throw caution to the wind (as I might have done), you could try adding the endingAfter parameter to your original request and including the current unix epoch. Otherwise, the API seems to return the oldest events.

HodyCrouch

Meraki's Location Analytics consider the connected time and signal strength of each client. If you don't include similar logic, your results will differ. I still wouldn't expect the numbers to match exactly. For details, go to help in Meraki dashboard and search for 3965. You can also use the "i" icon in Location Analytics to link to the help document.

HodyCrouch

How are you performing the timestamp conversion? When I convert 1548864847, I get Wednesday, January 30, 2019 11:14:07 AM GMT-05:00

HodyCrouch

I am not seeing this issue. I do have 2-factor authentication enabled for my account.

HodyCrouch · ‎01-16-2019

Does your account have full access at the organization level (not at the network level)?

HodyCrouch · ‎01-16-2019

Make sure the Dashboard API is enabled for your organization. Go to Meraki Dashboard > Organization > Settings. Look for the "API Access" setting.

HodyCrouch · ‎01-14-2019

When you see the 3 or 4 year term on the license information page, it's referring to the original length of the license. You can look at the 'Start date' column to learn when each license started. The '54 days' you see on the page means that your license will expire 54 days from now. Keep in mind that all Meraki licenses co-terminate for your entire network. Read this document to better understand the process https://documentation.meraki.com/zGeneral_Administration/Licensing/Cisco_Meraki_Licensing_Guidelines_and_Limitations/The_Science_Behind_Licensing_Co-Termination

HodyCrouch · ‎01-10-2019

You've probably already found this document. Make sure you start here: https://meraki.cisco.com/lib/pdf/meraki_whitepaper_captive_portal.pdf Look at the "EXCAP Overview - Sign-on Splash" section, which is pretty close to your use case. You can use the Walled Garden settings on your SSID to allow the user to interact with your site (to login and use their credits) while not providing access to everything else. You will need a back-end application to serve the captive portal pages, handle login, do the points exchange, terminate the session when the time limit is reached, and confirm authentication via RADIUS.

HodyCrouch · ‎01-07-2019

In cases like this, your only option is to make a lot of separate API calls. To avoid the API request limit, you can use a rate limiter. For example, I sometimes use the throttled-request package with Node.js. Remember that the rate limit applies at the organization level. If you have any other integrations or tasks using the API, you need to consider the total usage. Using the first two letters of the model to determine the device type seems good enough for now.

HodyCrouch · ‎12-18-2018

Try this: - Network-Wide > General - Traffic analysis > Custom Pie Chart > Add a Slice

HodyCrouch · ‎12-14-2018

If I'm reading this correctly, you want to set tuples in Meraki SM and access those key/value pairs from your custom Android application. Your application will need to use the RestrictionsManager object. Don't forget to check for changes when your app launches or resumes. You can also use intents to know when the configuration changes while your app is running. Further discussion is really outside of the scope of this forum. https://developer.android.com/reference/android/content/RestrictionsManager

HodyCrouch · ‎12-02-2018

When you add a license, you have the option of applying the license as additional devices or as a renewal. It looks like you added three of your licenses as renewals. As a result, you extended the expiration date of your one device rather than adding more devices to your network. You get a brief period when you can "undo" your license addition, which will let you correct the operation. That's why your screenshot has a circular arrow next to one of the licenses. If you don't have the "undo" option, you're going to have to contact Meraki support.

HodyCrouch · ‎11-30-2018

I use customized FreeRADIUS servers to handle authentication for Meraki in many locations. If you haven't already tried, I suggest running FreeRADIUS in debug mode ( radiusd -X ) and attempting to connect to your SSID. You will have to look through the FreeRADIUS output, but it should provide an indication of the root cause. Are you using Meraki's RADIUS proxy? Have you configured FreeRADIUS to accept connections from all possible IP addresses that can originate the RADIUS requests? The IP ranges will be different if you use Meraki's RADIUS proxy. If you aren't using Meraki's RADIUS proxy, have you checked firewall configurations between your access points and your RADIUS server?

HodyCrouch · ‎11-19-2018

When you go to the Clients view and select 'all clients with a policy', notice the 'i' that appears to the right of the time period filter. The pop-up says: " This view will show you all clients that have a policy, regardless of when they last transferred data. The usage data is for the selected time period." In other words, you should see all clients on the network that have a policy, even if they haven't had any activity in the last 30 days.

HodyCrouch · ‎10-30-2018

I'm not using Microsoft Teams, so I don't have a good way to test that end of the integration. However, I did a quick test yesterday with ngrok and a simple Node.js receiver. It took a little longer than I expected for the notifications to start arriving, but it did eventually work. I wasn't keeping close track, but I would guess that it was 10 or 15 minutes. I set my webhook to receive configuration change notifications only. I didn't add it to the top-level notification list. I then toggled a setting on the notification page a few times to cause the notifications to go out. Here's one of the notifications as an example to look at: { "alertData":{ "name":"Alerts", "url":"/manage/configure/alerts", "changes":{ "rogueAp":{ "label":"A rogue AP is detected", "oldText":"{\"enabled\":false}", "newText":"{\"enabled\":true}", "changedBy":"Someone (someone@company.com)", "ssidId":null } }, "userId":123456 }, "alertId":"1234567890123456789", "alertType":"Settings changed", "occurredAt":"2018-10-29T14:41:39.953568Z", "organizationId":"654321", "organizationName":"Org Name", "organizationUrl":"https://n123.meraki.com/o/5pWeda/manage/organization/overview", "networkId":"N_1234567890123456", "networkName":"A Network Name", "networkUrl":"https://n123.meraki.com/A-Network-Name/n/HakdfJH/manage/nodes/list", "version":"0.1", "sharedSecret":"asharedsecret", "sentAt":"2018-10-29T14:51:47.623106Z" }

HodyCrouch · ‎10-29-2018

Meraki does not validate the secret. Instead, the value is included in the payload sent to your environment. It's up to you to validate the secret (if you choose to do so). If you're not going to validate the shared secret, you can enter any value you want.

HodyCrouch · ‎10-02-2018

Yes, you would create two RF Profiles. You then assign the RF profiles to your access points using the Wireless > Radio Settings page. You will find settings for 5GHz-only, 2.4GHz-only, and dual-band (with optional steering) on the RF Profile page.

HodyCrouch

Community Record

Badges