Meraki

HodyCrouch · ‎Aug 15 2018

There's nothing exposed that you can configure. You should check the General page in Meraki dashboard where you set the POST URL. Do you see a green, yellow, or red circle next to it? You can see the response time of your endpoint (as seen by Meraki). If your endpoint is slow, Meraki appears to slow the flow of data. Otherwise, you should file a case with Meraki for them to investigate.

HodyCrouch · ‎Jul 30 2018

I believe the MR53 comes with mounting hardware for a drop-ceiling grid. Take a look at page 4 of the MR53 datasheet. The largest metal parts in the black foam twist on to the ceiling grid and are locked with set screws.

HodyCrouch · ‎Jul 28 2018

Are you perhaps getting the same response shown in https://community.meraki.com/t5/Solutions-APIs/Access-Control-Allow-Origin-error/td-p/9583 ? Last time I checked, Meraki did not support CORS on API calls. As a result, your cross-domain requests will fail at the browser level (see the post above for alternative approaches).

HodyCrouch · ‎Jul 19 2018

You can create a group policy that bypasses the splash page. You would then use MAC-based authentication and have your radius server set that group policy for known MAC addresses. For everyone else, the radius server would grant access without setting the group policy. Unknown MAC addresses would then see the splash page.

HodyCrouch · ‎Jun 21 2018

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 · ‎Jun 21 2018

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

HodyCrouch · ‎Jun 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 · ‎Jun 8 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 · ‎Jun 7 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 · ‎Jun 5 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 · ‎May 9 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 · ‎May 9 2018

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

HodyCrouch · ‎May 9 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 · ‎May 9 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 · ‎May 9 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 · ‎May 5 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 · ‎May 3 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 · ‎Apr 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 · ‎Apr 17 2018

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

HodyCrouch · ‎Apr 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 · ‎Apr 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 · ‎Apr 6 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 · ‎Apr 4 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 · ‎Mar 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 · ‎Mar 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.

About HodyCrouch

HodyCrouch

Community Record

Badges