About HodyCrouch

HodyCrouch

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

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

HodyCrouch

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

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

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

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

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

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 · ‎02-15-2018

Login to Meraki Dashboard and select the network containing the access point you want to remove. Wireless > Access points Click the checkbox next to the access point and select 'Remove from network' from the Edit dropdown. Organization > Inventory Click the checkbox next to the access point and click 'Remove from network' from the Edit dropdown.

HodyCrouch · ‎02-14-2018

As luck would have it, I ran into this exact issue this morning submitting a case. I received the same error about the CAPTCHA. In my case though, the 'I'm not a robot' box appeared below the case description field and I was able to check the box. It appears that Meraki is using Google's reCAPTCHA in an invisible mode. I'm guessing that if you don't 'pass' the check when you submit the case, the checkbox is supposed to appear, so that you can assert your non-robot-ness.

HodyCrouch · ‎02-09-2018

Have you looked at the Bulk Network Creator tool? Organization -> Bulk network creation You can download a sample spreadsheet from that page, update with all of your information, and upload the spreadsheet. It will geo-code your location addresses, create the networks, and add your access points. The following fields are supported: Network Name Serial (device/AP serial number) Network Tags Name (device/AP name) Tags (device/AP tags) Address Notes Static IP Netmask Gateway DNS1 DNS2 VLAN If I remember correctly, any omitted fields are automatically ignored.

HodyCrouch · ‎02-06-2018

The magic number seems to be 10 networks. The grouping of networks changes with the zoom level of the map, unless you have several networks positioned in the exact same spot on the map (it sounds like this is the case for you). When there are several networks in an area, they get grouped into a bigger marker on the map. Clicking on that marker causes the map to zoom in and display the networks separately (again, based on the zoom level of the map and the relative positions of the networks on the map). Of course, you can see the network status in the 'Network/Network tags/Devices' panel that floats over the map. You can use network tags or network names to quickly filter the list. For a high-level view, you can use the Network tags panel. If any networks are alerting, you will see the overall status for the tag reported as yellow or red. I'm not sure why, but it took a long time for me to notice the little triangle to expand the network panel that floats over the map. I find that expanded view to be especially useful. Otherwise, the only other option I see would be to reposition the networks so they are spread out on the map a bit. If you're depending on location information from the Scanning API, you definitely do not want to do this.

HodyCrouch · ‎02-02-2018

In case anyone else is interested, here's something I noticed this morning while tinkering with a smaller network. When I use a 'Wireless' configuration template rather than a 'Combined' configuration template, the behavior is different. When you view the list of networks bound to a configuration template, there's a 'Local overrides' column and a button 'Revert to template settings'. With a Combined configuration template, I don't get that column or button.

HodyCrouch · ‎02-01-2018

I should have been more clear. I know how I want the networks configured using templates, tags, and so on. I'm trying to clean up behind someone else. This may require some support 'magic' to get corrected. I thought I would see if there were any other solutions before going there. The API docs for PUT /networks/[networkId]/ssids/[number] contain an obscure note about the splashPage parameter being 'not supported for template children', but nothing similar on the other parameters that should be controlled by a template. We'll see if Dave has anything to add :)

HodyCrouch · ‎02-01-2018

I have a wireless network bound to a template. The template includes access control settings for splash page, association requirements, and so on. Even though the network is bound to the template, I get a limited set of access control options under the network where an admin can change the splash page (and a few other items). I believe this sets an exception to the template. A couple of questions: - how can I find out which networks contain these types of exceptions? When I view the access control page on networks where I know we haven't set any exceptions, the view is identical with items selected. - how can I remove the exception and have the network use the template settings instead?

HodyCrouch

Community Record