Hello @Enduro,   I would recommend opening a Meraki support case to help investigate further, if you have not done so already. An internal server error message is something that Meraki support can look for more information about internally.   Also, does the same message occur if you run the API call independently of Python? Postman and curl can both be leveraged for testing API calls too. ... View more

Hello StephenArcher,   Have you tried saving any other changes on the Addressing & VLANs page to see if that also generates an error? You could attempt to make a dummy static route or try updating a VLAN name to test this. Additionally, does clicking the save button at the bottom of the page produce the error message?   Sometimes vague error messages aren't directly related to the change you are making, but rather are an issue validating all settings across different pages. ... View more

Just want to update the thread, but the issue is resolved in Meraki Mobile App version 4.126.0. I was able to confirm from my own Organization that enabling or disabling a SSID using the Android version of the app works again.   Thank you @lloydz for reporting this issue and working with support! ... View more

Hello Ljalabs,   I thought that a Meraki device was the DHCP server just based on the log message, but did not want to assume, so that makes sense too.   As for what the shared event log messages indicate, that is a bit trickier. Just from experience, it could mean that those one of those 2 devices are actively taking extra leases that they're not supposed to. Does a packet capture show both devices replying to DHCP Offers from the MX when it is sent out? Also, are any other client devices having issues on VLAN 20, or is it just a singular device (which I assume is one of the 2 pictured in the event log)? Also, does the DHCP tab on the MX (Security & SD-WAN > Appliance status page) provide any clues to the amount of leases in use/consumed for VLAN 20? The DHCP tab on the MX shows what device has a DHCP lease assigned, so wondering if it shows one of those devices consuming more leases. ... View more

Hello Ljalabs,   The specific event log entry "extra: no_offers_received" indicates that the MX is seeing repeated DHCP Discovers from the listed client device; the MX does not have to be the DHCP server either, it just needs to see the repeated Discovers from the same client. If the DHCP Discovers are received 3 times within a 5 minute window, the MX logs the message in the event log. We have more specific information on the triggers and recommended troubleshooting steps here: https://documentation.meraki.com/MR/Monitoring_and_Reporting/DHCP_%22no_offers_received%22_Errors_in_the_Event_Log   As for why it might be appearing, that we would need more information about the environment. I know from experience it can indicate that there is a VLAN tagging issue on the port the AP is connected to, but that is not guaranteed to always be the case (and might not be occurring here, if there were no recent config changes, as you mentioned). As the article above mentions for troubleshooting steps, it can also indicate the DHCP server is not responding. Taking packet captures at various points in the network between DHCP server and client, and analyzing the captures for DHCP traffic could help determine where the breakdown is occurring. ... View more

Hello mrpackethead_   At this time RADSec is only supported on MR devices. MX/Z devices cannot use it. The features available for MX/Z wireless can be found here: https://documentation.meraki.com/MX/Wireless/MX_and_Z-Series_Wireless_Settings. I would recommend using the "Give your feedback" button on the lower right corner of any Dashboard page to request that RADSec be added to MX/Z wireless. ... View more

Hello Rafaelcabera,   The way the DNS VPN exclusion rules operate is that the MX must see an unencrypted DNS response (using UDP port 53) back to a client device. The response does not necessarily need to be a particular client, seeing a DNS response to any client is fine. The MX will then add this IP/hostname mapping to its cache for as long as the TTL specified in the DNS response is. Once that expires the MX would need to see a new DNS response for the hostname, which if the IP changes, the MX should record that new IP and breakout the traffic appropriately. We have this information and caveats documented here: https://documentation.meraki.com/MX/Site-to-site_VPN/VPN_Full-Tunnel_Exclusion_(Application_and_IP%2F%2FURL_Based_Local_Internet_Breakout)#Configuring_VPN_Exclusion_Rules_(DNS_Hostname)   This being said, Meraki support can check logging on the MX to make sure that mapping are correct along with looking into packet captures to see what the returned TTL in DNS query responses are. If you have not done so already, I would encourage you to open a support case so that support can look into logging and packet captures while the issue is happening with you. ... View more

Hello Shadius,   Is the issue that you are seeing the AP's IP for the 2 SSIDs using Meraki NAT mode or for all 3 SSIDs? It is expected for the 2 SSIDs using Meraki NAT mode, as the document that Brash shared explains.   Meraki NAT mode means that the AP provides IP addresses to clients connected to the SSID from the 10.0.0.0/8 subnet via DHCP. When a client sends traffic out to the network, the AP NATs the client's IP to its own management IP, masking what client actually sent the traffic. There is no way around this when using Meraki NAT mode either; client devices cannot be tracked behind NAT mode enabled SSIDs.   The bridge mode SSID, on the other hand, should not have this issue. You should be able to track clients connected to the SSID, as the client IPs are used within the wider network. ... View more

Hello everyone,   Engineering has begun the process of rolling out the fixes to MXs that we have identified as still impacted by the problem (these would be passthrough MXs that have not yet been rebooted). We appreciate your patience and the rollout should be completed soon.   Status updates can be found at status.meraki.net ... View more

@PhilipDAth July 21, 2026 is 22 months away 😋 So there's still quite a bit of time left that the AP model is supported.   @rsage_voda are there any more specifics that you can share about the setup? I tried a splash Meraki Cloud Auth using open (no encryption), external DHCP server assigned SSID + VLAN tagging with a CW9162i and MR52, both running MR30.7 and the splash page came up on my Android phone and tablet. Do you know if client devices were associating to the APs (so obtaining IPs) and it was the splash page specifically that failed to load? Are there any encryption settings that you have in place too? I can try adding those encryption settings to my own test lab network to see if they behave differently too. ... View more

Hello oubi,   Unfortunately what I had provided before will likely be necessary to obtain rogue AP or spoof SSIDs information. We do not have a more targeted API call or else I would have provided that as a response instead (or you may have found it too). The getNetworkEvents API call would contain the same information as found in the Network-wide > Monitor > Event log and does record some additional Air Marshal events that are not found from the getNetworkWirelessAirMarshal API call. All available event types that a provided network can be filtered for can be found using this API call: https://developer.cisco.com/meraki/api-v1/get-network-events-event-types/. And searching the output for a wireless network for "air marshal" should show the following 9 options: { "category": "Air Marshal", "type": "device_packet_flood", "description": "Single endpoint packet flood" }, { "category": "Air Marshal", "type": "packet_flood", "description": "Access point / client flood" }, { "category": "Air Marshal", "type": "bcast_deauth", "description": "Broadcasted deauthorizations" }, { "category": "Air Marshal", "type": "mac_spoofing_attack", "description": "Access point spoof" }, { "category": "Air Marshal", "type": "bcast_deauth_attack", "description": "Under containment" }, { "category": "Air Marshal", "type": "bcast_disassoc_attack", "description": "Under containment" }, { "category": "Air Marshal", "type": "bcast_disassoc", "description": "Broadcasted disassociations" }, { "category": "Air Marshal", "type": "rogue_ap_association", "description": "Rogue access point association" }, { "category": "Air Marshal", "type": "device_containment", "description": "Endpoint Containment" } You can also enable alerting from the Network-wide > Configure > Alerts page for a given network for when "A rogue access point is detected". Additionally you can enable SSID alerting within Air Marshal too: https://documentation.meraki.com/MR/Monitoring_and_Reporting/Air_Marshal#SSID_Alerting (these are provided in reference to your comment about wanting to be alerted by occurrences seen in Air Marshal).   I would also recommend using the "Give your feedback" button on the lower right corner of any Dashboard page to ask that additional Air Marshal API calls be added to target other pages viewable on Dashboard.  ... View more

Hello @lloydz,   If you have not done so already, can you open a Meraki support case to investigate this issue further? I do not have an Apple device to test with, but I do see the same behavior for Android on version 4.124.0 (latest version available in the Google Play Store). I can see from my Organization's change log that a mobile app request was logged, but SSIDs go from enabled: false -> enabled: false. You may want to confirm the change log behavior (and provide that detail to support too if you're seeing the same!). I also found that trying to disable a SSID behaves the same way; change log records information but SSID is still left enabled.   Additionally, if possible, taking a short video from your device (or of your device) may be the best way to show what is occurring when attempting to enable a SSID from the Meraki mobile app. ... View more

Hello @oubi,   The API call presented in the script does return rogue SSID information, but it does not mark it as a "rogue SSID" by name in a returned field. Instead you will need to rely on the definition of what a rogue SSID is in order to filter the returned information to find rogue SSIDs.   A rogue AP is an AP seen broadcasting a SSID but that is also connected to the LAN. Meraki APs in the network will see the MAC address and record it on the Wireless > Monitor > Air Marshal page. The Air Marshal API call returns a field for "wiredMacs", which if the SSID is not a rogue SSID, it will show []. If the SSID is a rogue SSID, the field will be returned with the MAC address(es) seen on LAN. You could use the "wiredMacs" not being [] to filter the provided JSON output to show rogue SSIDs.   Additionally, the API call in use will return information about SSID spoofs that exist in the network, albeit in a roundabout fashion. A SSID spoof is another device broadcasting the same SSID name that exists in the Meraki wireless environment, but is not detected on the LAN by Meraki APs. You can filter the returned JSON results from the API call to see if there are any matches for your own SSID names. Anything that shows up as a match would be a SSID spoof, as seen in Air Marshal.   AP spoofs however, will require a different API call. A spoofed AP would be reported as using the same MAC as a Meraki AP in the network, and the Air Marshal API call in use does not report device MAC addresses. Instead you could use the Network Events API call: https://developer.cisco.com/meraki/api-v1/get-network-events/ and filter for the includedEventTypes of "mac_spoofing_attack" for a given timespan. The results should match what is reported in Air Marshal, but the events will be for each instance that is seen (which could be multiple times if APs are repeatedly seeing the same AP spoof). But you could group the output from the events API call by MAC to match what Air Marshal provides on Dashboard. ... View more

Hello @Henk1961,   The Organization > Configure > Inventory tracks deployed and available devices only. Antennas, SFPs, and power supplies are not tracked using the Inventory page as they are accessories, not devices.   You can get the information about power supplies for all devices Organization-wide by using this API call: https://developer.cisco.com/meraki/api-v1/get-organization-devices-power-modules-statuses-by-device/. From Dashboard you can find the information from the "Power" tab on the Security & SD-WAN > Monitor > Appliance status page (for MXs, if applicable ) or from the Switching > Monitor > Switches page, then selecting a switch from the list. Switch models without power supplies will also have the "Power" tab, so it may take a lot of manual effort to validate information from the UI.   Unfortunately there are no API calls for SFPs or antennas. SFP information can be seen on a per port basis on switch ports, as long as the SFP provides that information to the switch. Additionally, this information is only available on switches. MXs do not provide that information on Dashboard.   Antennas on the other hand will most likely not show their information on Dashboard. Some antenna models are auto-detected by a connected AP and will automatically appear in Dashboard (specifically the antenna models mentioned here for the CW9163E: https://documentation.meraki.com/MR/Other_Topics/Frequently_Asked_Questions_regarding_Cisco_Meraki_Antennas#Which_Antennas_are_Supported_with_Which_Models_of_Access_Points.3F). Other antennas would need to be physically inspected to determine what model is connected. You could then use the "Notes" section on the AP to keep track of what is connected and use this API call: https://developer.cisco.com/meraki/api-v1/get-network-devices/ to obtain all devices in a network. If a note is added to the device, a field for "Notes" will be returned by the API call.   I would also recommend using the "Give your feedback" button on the lower right corner of any Dashboard page to request either an accessory inventory or accessories be added to the existing inventory on Dashboard. ... View more

Hello @jamesht,   At this time the issue with live data not populating on the MX uplink tab should be resolved. If you (or anyone else) are still experiencing issues with the MX uplink live data graph not showing any data, I would encourage you to open a support ticket to look into the issue further. Or if a ticket is already open and are still seeing problems with the live data graph, please update the ticket so that support can update our Engineering team. ... View more