Wireless Issue Resolution Guide

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:

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.

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:

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.

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:

• Signal to Noise ratio (SNR)

• Minimum bit rate

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.

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".

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".