About HodyCrouch

HodyCrouch

I take that back. I can't get this new API to work either. I've had success in the past with the similar API /api/v0/devices/[serial]/clients?timespan=7200 This returns all devices connected to a specified device. You would call this API for each device in a network.

HodyCrouch

Try adding the timespan parameter to your URL. https://api.meraki.com/api/v0/networks/{{networkId}}/clients/{{clientMac}}?timespan=7200

HodyCrouch · ‎06-11-2018

@Adam is correct. You also have the option of creating a Group Policy that only changes the splash behavior. Network Wide > Group Policies > Add a group Set Splash to 'Bypass' and leave everything else as 'Use SSID Default'. When you locate a client in the Network-Wide > Clients page, use the 'Apply Policy' option to apply your group policy.

HodyCrouch · ‎06-08-2018

I think you are being thwarted by your shell, probably because of the quotation marks. The hint is in the verbose output from curl. Content-Length: 53 However, your JSON is 59 characters long. I'm sitting at a Mac, and when I use your command line, curl attempts to send the correct 59 characters (I can't see if it will actually work, because I'm not going to mess with VLANs right now). You can try backslash-escaping the double-quotes or use the -d option in curl to read the post data from a file. curl --verbose -H "X-Cisco-Meraki-API-Key:~~~ed4c95773f7" -H "Content-Type:application/json" -X PUT --dat-binary "@postdata.txt" "https://api.meraki.com/api/v0/networks/N_682~~~86331/vlans/801"

HodyCrouch · ‎06-08-2018

I don't think you can do this with the Dashboard API. If you use the Scanning API, you can receive all currently connected wireless devices, including the SSID (if any). Of course, you can't query the Scanning API. You have to listen continuously.

HodyCrouch · ‎06-07-2018

I don't know of a way to get everything you've asked for in a CSV from Meraki dashboard. You can go to the 'View All Networks' page, expand the box that shows the list of networks on top of the map, add all available columns and click the CSV button. That will give you network name, type, client count, tags, template, and several other fields. In the same place, click on the 'Devices' tab (inside the floating box), add fields, and click the CSV button. That will give you MAC address, Public IP, Uplink IP, serial number, network name, and more. To get more details, you may have to use the Dashboard API. You can certainly get the lat/long of all devices from the API.

HodyCrouch · ‎06-05-2018

I believe the short answer is no. Meraki does support Per-AP SSID Availability through the use of AP tags and settings on the SSID Availability screen. You probably already found that feature. Even if Meraki supported the type of hybrid-SSID-broadcast that you describe, I don't think it would work in the way that you intend. I believe that wireless clients keep track of whether a stores profile references a broadcasting or non-broadcasting SSID. For broadcasting SSIDs, clients listen passively for the AP to advertise the SSID. For non-broadcasting SSIDs, the client actively attempts to connect. If your users associate to your SSID in an area where it's broadcasting, and later attempt to re-connect in a 'non-broadcasting' area, I don't think the device will connect. Roaming might be a different story, but then things could get really weird.

HodyCrouch · ‎05-09-2018

Yes. I have a pair of FreeRADIUS boxes running in AWS providing 802.1X authentication to a large number of sites through Meraki's RADIUS proxy.

HodyCrouch · ‎05-09-2018

I don't work for Cisco. It sounds like you might want to open a case with this question.

HodyCrouch · ‎05-09-2018

Yes, you need to add that CIDR range to your RADIUS server. The Access-Request messages will come from Meraki's data center, which is probably what you meant by saying Dashboard.

HodyCrouch · ‎05-09-2018

Look for a row with the description "802.1X with customer-hosted RADIUS" (you may see two rows). Ignore the row that starts with "Your network(s)". You would use this information if your RADIUS server was hosted in your own data center and needed a firewall rule for the outbound traffic. Look at the other row. The values in the "Source IP" column are what you need to add to your RADIUS server.

HodyCrouch · ‎05-09-2018

Use the RADIUS Proxy setting and then click on the "firewall information page" link to get a list IP addresses that will be used for RADIUS authentication. Add those IP addresses to your RADIUS server.

HodyCrouch · ‎05-05-2018

If you have access to the customer's Meraki organization, simply log in to Meraki dashboard, access the customer's organization, and go to Help - Cases. The customer will be able to see the case that you filed along with any updates. You can also use the phone numbers shown on the 'Get Help' page (in Meraki dashboard).

HodyCrouch · ‎05-03-2018

If you're trying to add a tag or modify the tag list, note that the inventory API does not include the current set of tags for each device. If you update the device attributes ( /networks/[networkId]/devices/[serial]), you will overwrite any existing tags. If that's okay with you, go for it. Otherwise, you will need to do a bit more work. Note that the tags parameter is a space-delimited set of tags. Instead, you can call the inventory API to get the list of devices, then get the device attributes for each device, parse the tag list and make any necessary changes, and then update the device attributes. It's really not that bad, but does require a little more code. One more thing, Meraki's APIs limit how quickly you can call them. If you're updating a lot of devices, make sure you throttle the requests. I think the official limit is 5 per second, although if I configure any higher than 3 per second, I get occasional failures.

HodyCrouch · ‎04-24-2018

Many years ago, I was helping with the residential network at a large college. After a student ordered a wired connection, we had to visit the proper wiring closet to connect their port and update the authorized MAC address. Perhaps the worst building involved walking up four flights of stairs, finding a small study room, opening a (fake) closet door, climbing a ladder, going through a ceiling hatch, walking across the entire building attic, climbing a very old wooden staircase to reach a steel door through a brick firewall, crossing another attic, and climbing a final staircase. One day, sweating in the summer heat, I was connecting a few student rooms when I heard a faint buzzing. The tiny room included ancient telephone connections, complete with 3/4" copper nubs, and not enough space to move around. At a lucky moment, someone received a phone call at the exact moment that my leg made contact with the array of copper connections. Ringing voltage will wake you up in a hurry. Did I mention that the relay rack was screwed down to rotting floorboards and would rock back-and-forth as you connected the patch cables? Cloud management has a special place in my heart.

HodyCrouch · ‎04-17-2018

I'm seeing the same behavior in one organization, but not in a few others that I checked.

HodyCrouch · ‎04-17-2018

I'm guessing here, but I think the association and authentication steps are limited to a single radius configuration (you can have several radius servers). MAC-based access control uses radius. Splash page sign-on uses radius. As a result, I don't think they can be used together. If you're already using "Sign-on with (my radius server)" with a custom splash page and you need MAC-based access control, you should be able to validate the MAC address on the same back-end handling your splash page. Oh well, it should be that easy, but it isn't. Sign-on splash uses a different URL than click-through splash (see https://meraki.cisco.com/lib/pdf/meraki_whitepaper_captive_portal.pdf). Sign-on splash doesn't appear to include the client MAC address in the URL. But all hope is not lost. I haven't tried this myself, but it should work... After the user completes the sign-on process, the Meraki AP sends a radius request to your server to confirm the credentials. This radius request SHOULD include the client MAC address. If I remember correctly, it's in the calling station id and the value is ALL CAPS, separated by dashes, followed by a colon, and followed by the SSID. Depending on your radius setup, you may be able to do the MAC filtering at this point.

HodyCrouch · ‎04-10-2018

Do you have walled garden settings in Wireless > Access Control for this SSID? If so, are you using IP Addresses or hostnames in the walled garden? You should verify that all resources on the survey page are permitted by your walled garden. Keep in mind that some resources may be associated to many different IP addresses.

HodyCrouch · ‎04-06-2018

I can't imagine that there's any way to capture the real wireless MAC address of a device probing with a locally administered MAC address until the device associates to the SSID. The entire reason why some devices use random/locally administered MAC addresses when probing is to prevent device tracking by access points.

HodyCrouch · ‎04-04-2018

As far as I can tell, the API does not support assigning group policies by ssid. I should point out that the documentation for setting the policy is incomplete (or inaccurate, depending on your point of view). The valid values for devicePolicy are whitelisted , blocked , normal , group. Note that "group policy" is not a valid value. You can see these values in Meraki's python library (https://github.com/meraki/dashboard-api-python/blob/master/meraki.py#L1327). If a device has group policies set by ssid, you can retrieve the details from the API. Here's what the response looks like: { "mac": "aa:bb:cc:dd:ee:ff", "type": "Different policies by SSID", "ssids": { 0: { "type": "Normal", "name": "ssid0" }, 1: { "type": "Group policy", "group_number": 100, "name": "ssid1" }, 2: { "type": "Whitelisted", "name": "ssid2" }, 14: { "type": "Blocked", "name": "ssid14" } } } Unfortunately, I don't see any way with the current API to set the client policy to something like that.

HodyCrouch · ‎03-21-2018

Could you try to be more clear about what you're trying to do, the exact steps you're taking, and the exact results you see? You can also contact Meraki support directly for assistance.

HodyCrouch · ‎03-21-2018

Try this: Go to Network Wide > Clients Open the drop-down next to the "Clients" title. It should say 'All' by default. Change the value to 'all clients with a policy' Locate your client on the list and change the group policy.

HodyCrouch · ‎02-27-2018

I certainly see a change in the available fields with "Download As \ CSV". However, I'm not limited to three fields. In the new version of the switches page, the CSV feature appears to include columns based on the visible columns on the current page. You can add fields using the wrench icon at the upper-right corner of the data table. After adding all available fields, I still can't get all of the columns that you mention. Some (not all) of this information is available through the Dashboard API.

HodyCrouch · ‎02-21-2018

You've already found the best documentation page, although it doesn't specifically address the MX65W (which doesn't show a dedicated 'Radio Settings' page). You can find the Country/Region for the MX65W by enabling at least one SSID on the MX65W (Security appliance > Wireless settings) and then scroll to the bottom of the page. If there's a conflict, you should see the warning and have the ability to request the change (based on the rules outlined in the documentation page you linked). I suspect that once you complete the change, you will be able to disable the SSID again. This might be a situation best left to a Case with Meraki support though.

HodyCrouch · ‎02-20-2018

Have you tried clicking the "Home" icon at the top of the map you see from Organization > Overview? When you hover over the home icon, you should see help text "Go to organization center" The map should center on the location of all devices in your network and zoom to a level that allows all devices to be seen.

HodyCrouch

Community Record