Catalyst 9800 Wireless Controller: Common Wireless Client Connectivity Issues

Overview

This document explains how to resolve common wireless client connectivity issues on Cisco Catalyst 9800 Wireless Controllers.

Prerequisites

Requirements

Knowledge of the following is recommended:

• Cisco Catalyst 9800 Series Wireless Controller
• Command Line Interface (CLI) access to the Wireless Controller

Components Used

• IOS XE Gibraltar 16.10 or later

The information in this document is based on devices in a specific lab environment. All devices used in this document were started in their default configuration.

Collecting Logs

The WLC 9800 provides a persistent trace feature that logs client connection-related errors, warnings, and informational messages. These logs can be reviewed to diagnose issues.

Note: The volume of logs generated can vary from a few hours to several days.

To collect logs:

1. Step 1: Check the controller's current time to track logs chronologically. Use the command: # show clock
2. Step 2: Collect Syslog from the controller's buffer or an external Syslog server. Use the command: # show logging
3. Step 3: Verify if debugging is enabled. Use the command: # show debugging
4. Step 4: Collect persistent trace logs for a specific MAC address. Use the command: # show logging profile wireless filter mac <mac_address> to-file always-on-<FILENAME.txt>

The trace logs can be viewed directly or copied to an external TFTP server.

Conditional Debugging and Wireless Active Traces

If persistent trace logs do not provide enough information, conditional debugging and Wireless Active (RA) traces can be enabled for processes interacting with specific conditions (like a client's MAC address).

1. Step 5: Clear existing platform conditions. Use the command: # clear platform condition all
2. Step 6: Enable debugging for the wireless client MAC address. Use the command: # debug wireless mac <mac_address> {monitor-time <seconds>}. This command monitors the specified MAC address for a set duration.
3. Step 7: Reproduce the issue.
4. Step 8: Stop debugging if the issue is reproduced before the monitor time expires. Use the command: # no debug wireless mac <mac_address>

After the monitor time elapses or debugging is stopped, the WLC 9800 generates a log file named ra_trace_MAC_...log.

Step 9: Collect the MAC address activity file. Use the command: # dir bootflash: | inc ra_trace to check the file name, and then copy it to an external server.

Step 10: If the root cause is still unclear, collect more verbose internal logs. Use the command: # show logging profile wireless internal filter { mac | ip } { <mac_address> | <ip_address> } to-file ra-internal-<FILENAME>.txt

Step 11: Remove debugging states. Use the command: # clear platform condition all

Scenarios

Scenario: Web Authentication Credentials Not Working

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-2}{1}: [auth-mgr] [8681]: (info): [0874.0277.1345:capwap_90000003] Authc failure from WebAuth, Auth event no-response

Cause:

• Client is not using valid credentials.
• No default allowed network is defined on the 9800 WLC.

Possible Solutions:

• Verify the client is using valid credentials.
• Add a default allowed network configuration.

GUI: Navigate to Configuration > Security > AAA > AAA Method List > Allowed and add a new allowed method configuration.

CLI:

# config t
# aaa authorization network default local

Scenario: Client Cannot Connect Due to Missing VLAN in Policy Profile

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-0}{1}: [epm] [25054]: UUID: 100000000019, ra: 15, (ERR):
EPM_PLUGIN_VLAN_ERR: [HDL = 0x0] Unable to get active_feature_ctx for vlan group name

Cause:

• No valid VLAN is defined in the policy profile assigned to the WLAN.

Solutions:

1. Verify the policy profile used by the client.

   GUI: Navigate to Monitoring > Wireless > Clients > Client Details > Client Properties. Look for the specific client using its MAC address.

   CLI: # show wireless client mac-address <mac_address> detail | inc Policy Profile

2. Verify which VLAN is assigned to that policy profile.

   GUI: Navigate to Configuration > Policy > Policy Profile > Access Policies and edit the policy profile.

   CLI: # show wireless profile policy detailed <policy-profile-name> | inc VLAN

3. Confirm that the VLAN name or VLAN ID is valid and active in the VLAN parameters.

   GUI: Navigate to Configuration > Layer2 > VLAN > VLAN.

   CLI: # show vlan brief

   Note: If using VLAN names, ensure case sensitivity matches the output of the show vlan brief command.

4. Configure the VLAN if necessary.

   GUI: Navigate back to Configuration > Policy > Policy Profile > Access Policies and configure the VLAN.

   CLI:

   # config t
   # wireless profile policy default-policy-profile
   # shutdown # vlan <vlan-# or vlan-name>
   # no shutdown

Scenario: Client Cannot Connect Due to Incorrect Password

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-1}{1}: [client-keymgmt] [27782]: UUID: 100000000088, ra: 15, (ERR):
MAC: e4b3.187c.3058 Keymgmt: Failed to validate eapol mic. MIC mismatch.

Cause:

• Client is entering an incorrect password.

Possible Solutions:

• Fix the password on the endpoint device.
• Fix the password for the SSID.

GUI: Navigate to Configuration > Wireless > WLAN > [WLAN Name] > Security > Layer2 and fix the password.

Scenario: Client Cannot Connect Because ACL Sent by RADIUS is Not Present on 9800 WLC

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-0}{1}: [epm-acl] [8104]: (ERR): ACL acl-sent-by-ise is
missing in configuration for mac e4b3.187c.3058

Cause:

• ACLs sent by RADIUS server are not present on the 9800 WLC.

Possible Solutions:

• Fix the RADIUS server configuration to send the correct ACL name.
• Add the missing ACL to the 9800 WLC.

Scenario: Client Cannot Connect Because VLAN Sent by RADIUS is Not Present on 9800 WLC

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-0}{1}: [epm] [8104]: (ERR): Error in activating feature (EPM
Vlan PLUG-IN)

Cause:

• VLANs sent by the RADIUS server are not present on the 9800 WLC.

Possible Solutions:

• Fix the RADIUS server configuration to send the correct VLAN name/ID.
• Add the missing VLAN to the 9800 WLC.

Scenario: Client Disconnected Due to WLAN or Policy Profile Change

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-0}{1}: [9800 WLC-infra-evq] [8522]: (note): Mcast: Sent L2
MGID 2602 DEL to AP vap_id 2

Cause:

• A change in the WLAN or policy profile manually disabled the SSID.

Solution:

• Avoid making changes to the SSID or policy profiles during production hours.

Scenario: Client Manually Removed from Network

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-0}{1}: [client-orch-sm] [8522]: (info): MAC: e4b3.187c.3058
Deleting the client, reason: 12, CO_CLIENT_DELETE_REASON_ADMIN_RESET, Client state S_CO_RUN

Cause:

• The client was manually removed from the network via CLI or GUI.

CLI Command: # wireless client mac-address <mac_address> deauthenticate

GUI: Navigate to Monitoring > Wireless > Clients and click Delete for the specific client.

Solution: This is normal behavior initiated by the user.

Scenario: EAP Timeout Causing Client Disconnection

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-2}{1}: [errmsg] [8681]: (note): %DOT1X-5-FAIL: Authentication
failed for client (0874.0277.1345) with reason (Timeout) on Interface capwap_90800003

Cause:

• The client is not responding to EAP packets sent by the 9800 WLC within the EAP request timeout interval and EAP request maximum retry count.

Possible Solutions:

• Update the wireless client driver to the latest version.
• Verify the wireless client trusts the RADIUS certificate.
• Increase the EAP request timeout and EAP request maximum retry count.

CLI:

# config t
# wireless security dot1x request retries <0-20>
# wireless security dot1x timeout <1-120 seconds>

GUI: Navigate to Configuration > Security > EAP to customize the necessary settings.

Scenario: AP Radio Reset Causing Client Disconnection

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-1}{1}: [apmgr-capwap-config] [8621]: (info): f07f.06ee.f590
Radio: 1 is Operationally DOWN.

Cause:

• The AP is causing a wireless reset related to channel change or power.

Possible Solutions:

• This is normal behavior.
• Configure the interval at which the 9800 WLC can perform channel changes.

CLI:

# config t
# ap dot11 { 5ghz | 24ghz } rrm channel dca interval <0-24>

GUI: Navigate to Configuration > Radio Configuration > RRM > 5 GHz Band/2.4 GHz Band > DCA > Increase Interval Setting.

Scenario: Web Authentication Timeout Causing Client Disconnection

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-2}{1}: [auth-mgr] [8681]: (info):
[0874.0277.1345:capwap_90000003] Authc failure from WebAuth, Auth event no-response

Cause:

• The client is not responding to WebAuth authentication requests within the Web authentication timeout interval.

Solution:

• Verify that the client completes Web authentication within 120 seconds.

Scenario: Session Timeout Causing Client Disconnection

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-1}{1}: [client-orch-sm] [8621]: (info): MAC: e4b3.187c.3058
Deleting the client, reason: 23, CO_CLIENT_DELETE_REASON_SESSION_TIMEOUT, Client state S_CO_RUN

Cause:

• The client has reached the session timeout.

Possible Solutions:

• Increase the session timeout for the associated SSID and policy profile.

CLI:

# config t
# wireless profile policy <policy-profile-name>
# shutdown
# session-timeout <20-86400 seconds>
# no shutdown

GUI: Navigate to Configuration > Policy > Policy Profile Name to customize the timer.

Scenario: Idle Timeout Causing Client Disconnection

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-0}{1}: [client-orch-sm] [7807]: (note): MAC: e4b3.187c.3058
Client delete initiated. Reason: CO_CLIENT_DELETE_REASON_MN_IDLE_TIMEOUT

Cause:

• The client did not send traffic (or sufficient traffic) within the idle timeout interval.

Possible Solutions:

• This is normal behavior.
• Customize the idle state settings for the associated SSID and policy profile.

CLI:

# config t
# wireless profile policy <policy-profile-name>
# shutdown
# idle-timeout <15-100000 seconds>
# idle-threshold <0-4294967295 bytes>
# no shutdown

GUI: Navigate to Configuration > Policy > Policy Profile Name to customize the idle state settings.

Note: If the idle state threshold is not set, clients will be disconnected if they do not send traffic within the timeout period. If the idle state threshold is set, clients must send at least 10 bytes of traffic every 30 seconds to avoid disconnection.

Scenario: Client Roaming Between SSIDs

Log Example:

YYYY/DD/MM HH:MM:SS.xxx {wncd_x_R0-0}{1}: [client-orch-sm] [7807]: (note): MAC: e4b3.187c.3058
Association received. BSSID f07f.06ee.f59d, old BSSID f07f.06ee.f59e, WLAN 1, Slot 1 AP
f07f.06ee.f590, 3702-02

Cause:

• The client connected to one SSID and then switched to another.

Possible Solutions:

• This is normal behavior.
• Remove the second SSID from the client.