Skip to main content
Cisco Meraki Documentation

Wireless Issue Resolution Guide

By Ankita Sakarkar



This article provides insight into the most recommended steps for resolving common wireless issues. Multiple factors contribute to the quality of the wireless environment. Below are the most common issues that one can run into in a wireless environment.

Learn more with these free online training courses on the Meraki Learning Hub:

Sign in with your Cisco SSO or create a free account to start training.

Clients Not Getting an IP Address

SSIDs in Bridge Mode

If the SSID the client is connecting to is configured to be in bridge mode, the client will be getting an IP address from the local DHCP server, there are few common issues related to DHCP & VLAN tags mentioned below:

Exhausted DHCP Pool

An exhausted DHCP pool is the most common reason responsible for DHCP issues. This is often caused because of a sudden increase in the number of clients using the network, so it's usually best to check for that first. The following steps can help to narrow down the scope of the issue:


  1. Create a test SSID in NAT mode and try to connect again with a client that is experiencing issues. This will help determine whether there are issues with local DHCP servers.
  2. Reduce the DHCP lease duration, if it is feasible to do so. Doing so may help clients experiencing DHCP addressing issues by freeing up more space in the addressing pool held by inactive devices.
  3. Run a packet capture on the AP’s wired interface and initiate the connection from an affected client multiple times. This is helpful for determining whether DHCP Offers or Requests are passing through the access point. Multiple captures and attempts are important to ensure you have a useful amount of data. Once you have downloaded a packet capture file, open it in Wireshark and use the filter “dhcp” to show DHCP packets. If we do not see DHCP Offers coming from the DHCP server or no Acknowledgment packets to the AP's wired interface, then there is likely an upstream or DHCP server issue. More information on DHCP flows on Netmania.

DHCP Server is Unreachable

When SSIDs are configured in bridge mode, clients depend on being able to reach a local DHCP server, so it is necessary that any APs have connectivity to a DHCP server. Often times, DHCP servers are hosted across a site-to-site VPN tunnel. In this case, the servers may become unreachable if: 


  • The DHCP server or site goes down
  • The tunnel to the DHCP server site goes down
  • Changes are made to the firewall rules on either end


Basic connectivity from the AP to the server can be tested by navigating to Wireless > Access point > Tools and pinging the IP address of the DHCP server. If the server is not responsive, then there may be a connection issue to the DHCP server somewhere upstream from the access point. Try following the connection to the DHCP server to determine where the break is.

Incorrect VLAN Tags

Incorrect VLAN tags are a common issue when SSIDs are tagged to be a part of a particular VLAN. The APs will hand out IP address to the clients on the tagged VLAN. This gets tricky as the client VLAN connection correlates to the port configuration of the upstream device the AP is plugged into.
For example, if the upstream port is configured as a trunk port with native VLAN 10 and the SSID is tagged with the same VLAN 10, the clients will never get an IP address as the upstream port drops packets tagged with its native VLAN.
The solution to this issue is to either remove the VLAN tag on the SSID or change the native VLAN on the upstream ports. More information can be found in the VLAN Tagging article.

SSIDs in NAT Mode

If the SSID the client is connecting to is configured to be in NAT mode, DHCP will not be an issue as the Meraki AP hands out the IP addresses to all the clients. However, the following steps can be followed to rule out the possibility that the AP is not handing out IP addresses:


  1. Try connecting the same client to another SSID. This will confirm whether the issue is only restricted to this particular SSID.
  2. Try connecting any other client to the same SSID. This will help narrow down the scope to determine whether the issue is only between one client and one SSID.
  3. Run a packet capture on the client machine using Wireshark to determine whether the ACK messages are being sent from the client to the AP, as the DHCP process will not complete unless we see the ACK message from the device.

Clients Unable to Connect to a Specific SSID

Check the Event Logs for the Devices

The event log for the client can be helpful in order to understand at what step the issue is being introduced. The event logs for the client can be accessed by navigating to Network Wide > Monitor > Client or filtering the network-wide event log using the Mac address of the client.

Verify the Credentials

When a client is unable to connect to a specific SSID, incorrect credentials (username or password) are the most common issue. This issue can often be ruled out by simply deleting the SSID from the device, trying to connect again and then re-typing the pre-shared key.

Sometimes when a pre-shared key for an SSID is recently changed on the dashboard using Google Chrome, the old value may be cached and the key is never actually changed. It's important to verify that any changes to the pre-shared key are actually applied and saved. It is a good practice to change such a setting in a private browser and re-verifying that the changes were saved properly. When using RADIUS or  AD authentication it is a good troubleshooting step to re-verify the credentials for AD, and the RADIUS server credentials as well. More information for the RADIUS troubleshooting can be found in the RADIUS Issue Resolution Guide.


Failed connections can be checked by navigating to Wireless > Wireless Health > Connections and then clicking on the failed connection. This will generate a report for all the failed connection as shown in the image below:


Faiiled connections.png

Clients not Able to Connect to a Specific AP

Test an SSID with Minimal Configuration Settings

Generally, the best way to resolve an issue with a client not being able to connect to a specific AP will be by creating a basic test SSID with as few configuration settings applied to it as possible.

Try creating and testing connectivity to an SSID with the following settings:


  • Association requirements: Pre-shared key or Open
  • Splash page: None
  • Client IP assignment: NAT mode
  • Band selection: Dual band operation
  • Minimum bitrate: 1


If you want to contain your test, go to Wireless > SSID Availability and tag the SSID with the AP's tag so that only the AP in question broadcasts it. 

These settings will remove all the third parties involved and make it easier to diagnose the issue between the client and the access point. This also prevents disturbing the entire network when only one AP is in question.


Meraki Authentication can be used as an alternative to RADIUS Authentication for testing as the basic functionalities are similar. Meraki Authentication uses a Meraki hosted RADIUS server, and testing with this may be helpful for identifying local or client-side RADIUS issues.

Verify Upstream Settings

Check the upstream port configuration. If the port the AP is connected to doesn't pass traffic on the VLAN the client is on, the client may have connection issues. If possible try swapping the AP from its current port to a port being used by another working AP or another known-working device. This will rule out the upstream port is at fault.

Reboot the AP

Rebooting the AP can be helpful to check whether reinitiating all processes helps to get the AP to a stable state.

Clients not Getting Internet Connectivity

Often times, clients are fully connected to an AP have a valid IP address, but still cannot reach the Internet. In this case, try the following:


  1. Verify that the gateway is correct and reachable. Try pinging the gateway from the client and from the AP.

  2. Try changing the DNS server to Google’s public DNS ( DNS issues are one of the most common client connection issues.

  3. Check to see if any firewall rules & group policies are applied to that particular client or entire subnet. This can be verified by navigating to Network-wide > Client and then clicking on the client and checking for the network policy.

Clients Connect to a Far Away AP

Client-Side Behavior

The access points act as a bridge between devices and the local network infrastructure. The initial association process is explained in the 802.11 Association Process article. The decision for which AP to connect to is completely made by the client and there is no way to force a client to connect to a particular AP. However, the client's decision can be influenced by using the correct configuration settings.

Various factors influence the client's decision of which AP it should connect to. The main factors that can be manipulated to affect this are:

Not all devices have the capabilities to first calculate the signal-to-noise ratio of all the available APs around and pick the one with the best signal strength. Most clients simply connect to the first AP they see and will try to stay connected the same one until the signal is lost. This might result in one AP getting overloaded while the rest of them are idle. This can be mitigated by turning on Client Balancing.

Settings That Can Be Implemented to Avoid Sticky Client Issues

Minimum bit rate and transmitting power are AP parameters that can be manipulated to avoid the sticky client condition. The exact numbers for these settings are subjective, depending on the wireless environment and the parameter that influences the particular client the most.


For example, we have two APs (AP1, AP2), and a client device PC. The minimum bit rate is set to 12.




Initially, when the client PC visits the site for the first time, the device connects to AP1. When roaming around the facility, even when the PC gets close to AP2, it still stays connected to AP1. The diagram below shows the values for the SNR & bit rate (again, these values are subjective). We see that the device is close to AP2 while having all the minimum requirements for the bit rate being satisfied with its already existing connection, so the chances are that the PC will not connect to AP2 even when it is the closest AP.


This can be changed by either reducing the Transmit Power or Increasing the bit rate. However, there are multiple factors that need to be taken into consideration while making these changes, as it may affect the wireless performance of other devices. It's important to consider that not all the devices may support the high bit rate & reducing the transmit power can affect the coverage.

Site Survey For Optimal Performance

To have a proper understanding of the wireless environment, the best option is to conduct a site survey of the wireless infrastructure. The information regarding the tools and best practices for a site survey is explained in the documentation Conducting Site Surveys with MR Access Points.

Specific Error in the Event Logs

client has left AP

This event is logged when the client informs the AP that it no longer wants to be associated. This could be the result of several factors, including the client going to sleep, low power mode or roaming away to another AP. The picture below shows the event logs with the type "802.11 disassociation" with reason "client has left the AP".


Client left the ap.png

unknown reason

This event implies that the client left the AP and there is not enough data for providing exact reasoning. Very often, this is because the device failed to notify the AP before disassociating. The picture below shows the event logs with the types "802.11 disassociation" with reason "unknown reason".


unknown reasons.png


Poor Throughput Due to RF Performance 

RF settings are generally the main factor that directly corresponds to throughput and overall wireless performance. If any of the 2.4 GHz or 5 GHz bands are being highly utilized, this can considerably degrade the performance of the wireless network. More information on the wireless interference can be found in the Common Sources for Wireless Interference article.


Most Meraki access points have a dedicated WIPS (Air Marshal) radio that is equipped to do a real-time spectrum analysis and will populate the results on the dashboard. These results will give an idea of which band is getting over-utilized and on which channels it is being used. This information can be found on the dashboard under Wireless > RF spectrum. Check the RF Spectrum Page Overview for more information on how to analyze this data.


It is a good practice to have the channel setting set to Auto Channel. This setting gives the AP the ability to switch the channels after it detects a jammed channel. When AP decides to move the clients to another channel, it sends out a Channel Switch Announcement (CSA) to all the clients currently connected, in an attempt to help them maintain their connection to the same AP. However, many clients do not support CSA on the 2.4 GHz spectrum, which means the clients will be disconnected and they will have to re-associate.


An example of a good RF Environment is shown in the diagram below. For most access points, the bands have low to moderate utilization, and not many overlapping channels are observed. However, for AP “4.32” it is showing high utilization on 2.4 GHz.



If a particular band is getting over utilized, the issue can be narrowed down more by checking the following:

  • Which band is getting over utilized?

  • What channels are being used by all the APs for that band?

  • Are all the APs using similar channels with respect to each band?


If one particular band for multiple APs is being highly utilized, try configuring the Manual Channel assignment to prevent the AP from using similar channels. In the example above, we can try changing the channels used by “4.32” AP for the 2.4 GHz from 6 (which is currently being used) to 11 which is used by fewer APs.


However, note that making any radio changes will kick off the existing clients, so it is recommended to make this change outside of business hours. This example gives us an overview of how to change the necessary setting to get the optimal RF environment, but this is subjective as each wireless network is different and has a wide range of client types contributing to the RF environment as a whole.

Wireless Network Unable to Access Local LAN

Meraki APs let you configure layer 3 firewall rules per SSID. There is a high probability that one of these rules is blocking access to the local LAN. The best troubleshooting steps would be:

  1. Check whether the SSID is in NAT mode. If it is, navigate to Wireless > Firewall & Traffic shaping Rules >  Layer 3 firewall rule access to Local LAN. If it is set to Deny, set it to Allow.

  2. Check whether there are any other upstream layer 3 rules for that subnet when using SSID in bridge mode. These rules may be blocking wireless traffic from the local LAN.

  3. Check whether Client Isolation is enabled. If it is, try temporarily disabling it to see if access to the local LAN becomes available.

Splash Page Issues

Splash page issues are some of the most commonly encountered issues, as splash page is one of the most widely used wireless features. 

To resolve splash page issues, check the Splash Page Traffic Flow & Troubleshooting steps for the common issues affecting the different types of splash pages. 

Avoiding Wireless Issues with Best Practice Planning

This article sums up the most commonly encountered issues and troubleshooting steps for wireless. However, these issues can be mitigated and reduced considerably by following Best practices for MR Wireless Design when designing the network.