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

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. ... View more

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. ... View more

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. ... View more

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. ... View more

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. ... View more

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. ... View more

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

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

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

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. ... View more

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. ... View more

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

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. ... View more

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? ... View more

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" } ... View more

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. ... View more

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. ... View more

I had to submit a case to Meraki support to get access to the Wireless Health APIs.  Until then, I received a 404 on any requests to that set of APIs.   Also, make sure you use valid values for t0 and t1.  I don't think you can submit 0 and 3600 (as you did in your example) to get the last hour.  Instead, you need to specify unix epoch values (see https://www.epochconverter.com/ if you are unfamiliar).   @PhilipDAth - I played around with connectionStats in hope that it would provide client counts or connection status for specific clients.  As far as I can tell, that's not what the API does.  Instead, the API provides the same type of information shown in the dashboard UI for Wireless Health.  The connectionStats object only seems to show information when a client attempted to establish a connection during the specified time window.   For example, one of my networks has 8 active clients.  When I query connectionStats for the last hour, I receive an empty array as a reply.  If I query for the last 3 hours, I only see a single entry for a device that happened to disassociate and re-associate at that time.   Unless I'm missing something, I don't see how the Wireless Health APIs can provide current client status information. ... View more

  Meraki describes the hash algorithm in pseudocode:     hash(mac bytes, org secret) = SHA1(mac bytes ++ org secret).takeRight(4) where: ++ indicates concatenation; takeRight(4) returns the least significant 4 bytes of the SHA1; and org secret is a per-customer salt. Example: client MAC is 11:22:33:44:55:66 org secret is t3lrdd least significant 4 bytes of SHA1(112233445566t3Irdd) = 0x0e456406   I'm not sure why you would want to implement this yourself, but here's an example in Node.js   var crypto = require('crypto'); merakiHash('11:22:33:44:55:66', 't3Irdd'); function merakiHash(mac, secret) { var sha1 = crypto.createHash('sha1'); var macBytes = mac.replace(/:/g, ''); sha1.update(Buffer.from(macBytes, 'hex')); sha1.update(secret); var hashResult = sha1.digest('hex').slice(-8); console.log('least significant 4 bytes of SHA1(' + macBytes + secret + ') = 0x' + hashResult); return hashResult; }   For any Meraki people following along, would you mind updating the docs?  The comment in your pseudocode uses a different org secret than the example, which made this a little more painful than it should have been.  "t3lrdd" is not the same as "t3Irdd".     ... View more