Troubleshooting Wireless Issues

Exhausted DHCP Pool

An exhausted DHCP pool is the most common cause of DHCP issues. A sudden increase in the number of clients using the network often triggers this condition. Follow these steps 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 step helps determine whether the issue is with the local DHCP server. 
2. Reduce the DHCP lease duration, if feasible. Reducing the lease duration frees up address space held by inactive devices. 
3. Run a packet capture on the AP's wired interface and initiate the connection from an affected client multiple time. This is helpful for determining whether DHCP Offers or Requests are passing through the AP. Multiple captures and attempts are important to ensure you have a useful amount of data.

Follow these steps to analyze the capture:  

1. Download the packet capture file.  
2. Open the file in Wireshark .  
3. Apply the filter "dhcp" to display DHCP packets.  
4. Check whether DHCP Offers are coming from the DHCP server and whether acknowledgment packets are reaching the AP's wired interface. 
5. If DHCP Offers are not coming from the DHCP server, or Acknowledgment packets are not reaching the AP's wired interface, an upstream or DHCP server issue is likely. For more information on DHCP flows, refer to the Netmania.

DHCP Server is unreachable

When SSIDs are configured in bridge mode, clients depend on reaching a local DHCP server. Any AP must have connectivity to a DHCP server. DHCP servers are often hosted across a site-to-site VPN tunnel and may become unreachable in the following situations: 

• The DHCP server or site goes down 

• The tunnel to the DHCP server site goes down 

• Firewall rule changes are made on either end 

To test basic connectivity from the AP to the server, navigate to Wireless > Access point > Tools and ping the IP address of the DHCP server. If the server is not responsive, a connection issue exists somewhere upstream from the AP. Trace the connection to the DHCP server to identify where the break occurs.

Incorrect VLAN tags

Incorrect VLAN tags are a common issue when SSIDs are tagged to a particular VLAN. The APs assign IP addresses to clients on the tagged VLAN. The client VLAN connection depends on the port configuration of the upstream device the AP is connected to. 

For example, if the upstream port is configured as a trunk port with native VLAN 10, and the SSID is tagged with VLAN 10, clients will not receive an IP address. 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. For more information, refer to the VLAN Tagging article. 

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.

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

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

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

4. 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, move the AP to a port used by another working AP or a known working device. This rules out the upstream port as the cause. 

Reboot the AP

Rebooting the AP helps determine whether reinitializing all processes returns the AP to a stable state. 

Understand client-side behavior 

1. APs 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 client determines which AP to connect to. 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. 

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

3. Not all devices have the capabilities to first calculate the SNR of all the available APs around and pick the one with the best signal strength. Most clients connect to the first AP detected and remain connected until the signal is lost. This behavior can result in one AP becoming overloaded while other remain idle. Enabling Client Balancing can mitigate this condition. 

Implement settings to avoid sticky client issues 

Minimum bit rate and transmit power are AP parameters that can be adjusted to avoid the sticky client condition. The optimal values for these settings depend on the wireless environment and the specific client behavior.

For example, consider two APs (AP1 and AP2) and a client device with the minimum bit rate set to 12. When the client PC visits the site for the first time, the device connects to AP1. When roaming around the facility, even when the client PC gets close to AP2, the client remains connected to AP1. The SNR and bit rate values are subjective. The device is close to AP2 while having all the minimum bit rate requirements satisfied with the existing connection. The client PC will likely not connect to AP2 even when AP2 is the closest AP. 

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.

To address this behavior, either reduce the Transmit Power or increase the minimum bit rate. Consider the following before making these changes, as these adjustments may affect the wireless performance of other devices: 

• Not all devices support high bit rates. 
• Reducing transmit power may affect coverage. 

Conduct a site survey for optimal performance 

To understand the wireless environment fully, conduct a site survey of the wireless infrastructure. For information on tools and best practices, refer to the Conducting Site Surveys with MR Access Points documentation.

Check specific errors in the event logs