Cisco Wireless LAN Controller Configuration Guide, Release 6.0

Interpreting Controller LEDs

Refer to the quick start guide for your specific controller for a description of the LED patterns.

Interpreting Lightweight Access Point LEDs

Refer to the quick start guide or hardware installation guide for your specific access point for a description of the LED patterns.

Using the GUI to Configure System and Message Logging

Using the GUI, follow these steps to configure system and message logging.

Step 1 Choose Management > Logs > Config . The Syslog Configuration page appears (see Figure 2).

Figure 2 Syslog Configuration Page

Step 2 In the Syslog Server IP Address field, enter the IP address of the server to which to send the syslog messages and click Add . You can add up to three syslog servers to the controller. The list of syslog servers that have already been added to the controller appears below this field.

Note If you ever want to remove a syslog server from the controller, click Remove to the right of the desired server.

Step 3 To set the severity level for filtering syslog messages to the syslog servers, choose one of the following options from the Syslog Level drop-down box:

• Emergencies = Severity level 0
• Alerts = Severity level 1 (default value)
• Critical = Severity level 2
• Errors = Severity level 3
• Warnings = Severity level 4
• Notifications = Severity level 5
• Informational = Severity level 6
• Debugging = Severity level 7

If you set a syslog level, only those messages whose severity is equal to or less than that level are sent to the syslog servers. For example, if you set the syslog level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are sent to the syslog servers.

Step 4 To set the facility for outgoing syslog messages to the syslog servers, choose one of the following options from the Syslog Facility drop-down box:

• Kernel = Facility level 0
• User Process = Facility level 1
• Mail = Facility level 2
• System Daemons = Facility level 3
• Authorization = Facility level 4
• Syslog = Facility level 5 (default value)
• Line Printer = Facility level 6
• USENET = Facility level 7
• Unix-to-Unix Cop y = Facility level 8
• Cron = Facility level 9
• FTP Daemon = Facility level 11
• System Use 1 = Facility level 12
• System Use 2 = Facility level 13
• System Use 3 = Facility level 14
• System Use 4 = Facility level 15
• Local Use 0 = Facility level 16
• Local Use 1 = Facility level 17
• Local Use 2 = Facility level 18
• Local Use 3 = Facility level 19
• Local Use 4 = Facility level 20
• Local Use 5 = Facility level 21
• Local Use 6 = Facility level 22
• Local Use 7 = Facility level 23

Step 5 Click Apply to commit your changes.

Step 6 To set the severity level for logging messages to the controller buffer and console, choose one of the following options from both the Buffered Log Level and Console Log Level drop-down boxes:

• Emergencies = Severity level 0
• Alerts = Severity level 1
• Critical = Severity level 2
• Errors = Severity level 3 (default value)
• Warnings = Severity level 4
• Notifications = Severity level 5
• Informational = Severity level 6
• Debugging = Severity level 7

If you set a logging level, only those messages whose severity is equal to or less than that level are logged by the controller. For example, if you set the logging level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are logged.

Step 7 Check the File Info check box if you want the message logs to include information about the source file. The default value is enabled.

Step 8 Check the Proc Info check box if you want the message logs to include process information. The default value is disabled.

Step 9 Check the Trace Info check box if you want the message logs to include traceback information. The default value is disabled.

Step 10 Click Apply to commit your changes.

Step 11 Click Save Configuration to save your changes.

Using the GUI to View Message Logs

To view message logs using the controller GUI, choose Management > Logs > Message Logs . The Message Logs page appears (see Figure 3).

Figure 3 Message Logs Page

Note To clear the current message logs from the controller, click Clear.

Using the CLI to Configure System and Message Logging

Using the CLI, follow these steps to configure system and message logging.

Step 1 To enable system logging and set the IP address of the syslog server to which to send the syslog messages, enter this command:

config logging syslog host server_IP_address

You can add up to three syslog servers to the controller.

Note To remove a syslog server from the controller, enter this command:
config logging syslog host server_IP_address delete

Step 2 To set the severity level for filtering syslog messages to the syslog server, enter this command:

config logging syslog level severity_level

where severity_level is one of the following:

• emergencies = Severity level 0
• alerts = Severity level 1
• critical = Severity level 2
• errors = Severity level 3
• warnings = Severity level 4
• notifications = Severity level 5
• informational = Severity level 6
• debugging = Severity level 7

Note As an alternative, you can enter a number from 0 through 7 for the severity_level parameter.

Note If you set a syslog level, only those messages whose severity is equal to or less than that level are sent to the syslog server. For example, if you set the syslog level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are sent to the syslog server.

Step 3 To set the severity level for filtering syslog messages for a particular access point or for all access points, enter this command:

config ap logging syslog level severity_level {Cisco_AP | all }

where severity_level is one of the following:

• emergencies = Severity level 0
• alerts = Severity level 1
• critical = Severity level 2
• errors = Severity level 3
• warnings = Severity level 4
• notifications = Severity level 5
• informational = Severity level 6
• debugging = Severity level 7

Note If you set a syslog level, only those messages whose severity is equal to or less than that level are sent to the access point. For example, if you set the syslog level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are sent to the access point.

Step 4 To set the facility for outgoing syslog messages to the syslog server, enter this command:

config logging syslog facility facility_code

where facility_code is one of the following:

• authorization = Authorization system. Facility level = 4.
• auth-private = Authorization system (private). Facility level = 10.
• cron = Cron/at facility. Facility level = 9.
• daemon = System daemons. Facility level = 3.
• ftp = FTP daemon. Facility level = 11.
• kern = Kernel. Facility level = 0.
• local0 = Local use. Facility level = 16.
• local1 = Local use. Facility level = 17.
• local2 = Local use. Facility level = 18.
• local3 = Local use. Facility level = 19.
• local4 = Local use. Facility level = 20.
• local5 = Local use. Facility level = 21.
• local6 = Local use. Facility level = 22.
• local7 = Local use. Facility level = 23.
• lpr = Line printer system. Facility level = 6.
• mail = Mail system. Facility level = 2.
• news = USENET news. Facility level = 7.
• sys12 = System use. Facility level = 12.
• sys13 = System use. Facility level = 13.
• sys14 = System use. Facility level = 14.
• sys15 = System use. Facility level = 15.
• syslog = The syslog itself. Facility level = 5.
• user = User process. Facility level = 1.
• uucp = Unix-to-Unix copy system. Facility level = 8.

Step 5 To set the severity level for logging messages to the controller buffer and console, enter these commands:

• config logging buffered severity_level
• config logging console severity_level

where severity_level is one of the following:

• emergencies = Severity level 0
• alerts = Severity level 1
• critical = Severity level 2
• errors = Severity level 3
• warnings = Severity level 4
• notifications = Severity level 5
• informational = Severity level 6
• debugging = Severity level 7

Note As an alternative, you can enter a number from 0 through 7 for the severity_level parameter.

Note If you set a logging level, only those messages whose severity is equal to or less than that level are logged by the controller. For example, if you set the logging level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are logged.

Step 6 To save debug messages to the controller buffer, the controller console, or a syslog server, enter these commands:

• config logging debug buffered { enable | disable }
• config logging debug console { enable | disable }
• config logging debug syslog { enable | disable }

By default, the console command is enabled, and the buffered and syslog commands are disabled.

Step 7 To cause the controller to include information about the source file in the message logs or to prevent the controller from displaying this information, enter this command:

config logging fileinfo { enable | disable }

The default value is enabled.

Step 8 To cause the controller to include process information in the message logs or to prevent the controller from displaying this information, enter this command:

config logging procinfo { enable | disable }

The default value is disabled.

Step 9 To cause the controller to include traceback information in the message logs or to prevent the controller from displaying this information, enter this command:

config logging traceinfo { enable | disable }

The default value is disabled.

Step 10 To enable or disable timestamps in log messages and debug messages, enter these commands:

• config service timestamps log { datetime | disable }
• config service timestamps debug { datetime | disable }

where

– datetime = Messages are timestamped with the standard date and time. This is the default value.

– disable = Messages are not timestamped.

Step 11 To save your changes, enter this command:

save config

Using the CLI to View System and Message Logs

To see the logging parameters and buffer contents, enter this command:

show logging

Information similar to the following appears:

Using the GUI to Upload Logs and Crash Files

Using the controller GUI, follow these steps to upload logs and crash files.

Step 1 Choose Command > Upload File . The Upload File from Controller page appears (see Figure 4).

Figure 4 Upload File from Controller Page

Step 2 From the File Type drop-down box, choose one of the following:

• Event Log
• Message Log
• Trap Log
• Crash File

Step 3 From the Transfer Mode drop-down box, choose TFTP or FTP .

Step 4 In the IP Address field, enter the IP address of the TFTP or FTP server.

Step 5 In the File Path field, enter the directory path of the log or crash file.

Step 6 In the File Name field, enter the name of the log or crash file.

Step 7 If you chose FTP as the Transfer Mode, follow these steps:

a. In the Server Login Username field, enter the FTP server login name.

b. In the Server Login Password field, enter the FTP server login password.

c. In the Server Port Number field, enter the port number of the FTP server. The default value for the server port is 21.

Step 8 Click Upload to upload the log or crash file from the controller. A message appears indicating the status of the upload.

Using the CLI to Upload Logs and Crash Files

Using the controller CLI, follow these steps to upload logs and crash files.

Step 1 To transfer the file from the controller to a TFTP or FTP server, enter this command:

transfer upload mode { tftp | ftp }

Step 2 To specify the type of file to be uploaded, enter this command:

transfer upload datatype datatype

where datatype is one of the following options:

• crashfile —Uploads the system’s crash file.
• errorlog —Uploads the system’s error log.
• panic-crash-file—Uploads the kernel panic information if a kernel panic occurs.
• systemtrace —Uploads the system’s trace file.
• traplog —Uploads the system’s trap log.
• watchdog-crash-file —Uploads the console dump resulting from a software-watchdog-initiated reboot of the controller following a crash. The software watchdog module periodically checks the integrity of the internal software and makes sure that the system does not stay in an inconsistent or non-operational state for a long period of time.

Step 3 To specify the path to the file, enter these commands:

• transfer upload serverip server_ip_address
• transfer upload path server_path_to_file
• transfer upload filename filename

Step 4 If you are using an FTP server, also enter these commands:

• transfer upload username username
• transfer upload password password
• transfer upload port port

Note The default value for the port parameter is 21.

Step 5 To view the updated settings, enter this command:

transfer upload start

Step 6 When prompted to confirm the current settings and start the software upload, answer y.

Configuring the Controller to Automatically Upload Core Dumps to an FTP Server

Using the GUI to Configure the Controller to Automatically Upload Core Dumps to an FTP Server

Using the controller GUI, follow these steps to enable the controller to automatically upload a core dump file to an FTP server.

Step 1 Choose Management > Tech Support > Core Dump to open the Core Dump page (see Figure 5).

Figure 5 Core Dump Page

Step 2 To enable the controller to generate a core dump file following a crash, check the Core Dump Transfer check box.

Step 3 To specify the type of server to which the core dump file is uploaded, choose FTP from the Transfer Mode drop-down box.

Step 4 In the IP Address field, enter the IP address of the FTP server.

Note The controller must be able to reach the FTP server.

Step 5 In the File Name field, enter the name that the controller uses to label the core dump file.

Step 6 In the User Name field, enter the username for FTP login.

Step 7 In the Password field, enter the password for FTP login.

Step 8 Click Apply to commit your changes.

Step 9 Click Save Configuration to save your changes.

Using the CLI to Configure the Controller to Automatically Upload Core Dumps to an FTP Server

Using the controller CLI, follow these steps to enable the controller to automatically upload a core dump file to an FTP server.

Step 1 To enable or disable the controller to generate a core dump file following a crash, enter this command:

config coredump {enable | disable}

Step 2 To specify the FTP server to which the core dump file is uploaded, enter this command:

config coredump ftp server_ip_address filename

where

• server_ip_address is the IP address of the FTP server to which the controller sends its core dump file, and

Note The controller must be able to reach the FTP server.

• filename is the name that the controller uses to label the core dump file.

Step 3 To specify the username and password for FTP login, enter this command:

config coredump username ftp_username password ftp_password

Step 4 To save your changes, enter this command:

save config

Step 5 To see a summary of the controller’s core dump file, enter this command:

show coredump summary

Information similar to the following appears:

Uploading Core Dumps from a 5500 Series Controller to a TFTP or FTP Server

Using the controller CLI, follow these steps to upload the core dump file from the flash memory of a 5500 series controller to a TFTP or FTP server.

Step 1 To see information about the core dump file in flash memory, enter this command:

show coredump summary

Information similar to the following appears:

Step 2 To transfer the file from the controller to a TFTP or FTP server, enter these commands:

• transfer upload mode { tftp | ftp }
• transfer upload datatype coredump
• transfer upload serverip server_ip_address
• transfer upload path server_path_to_file
• transfer upload filename filename

Note After the file is uploaded, it ends with a .gz suffix. If desired, you can upload the same core dump file multiple times with different names to different servers.

Step 3 If you are using an FTP server, also enter these commands:

• transfer upload username username
• transfer upload password password
• transfer upload port port

Note The default value for the port parameter is 21.

Step 4 To view the updated settings, enter this command:

transfer upload start

Step 5 When prompted to confirm the current settings and start the software upload, answer y.

Using the GUI to Upload Packet Capture Files

Using the controller GUI, follow these steps to upload a packet capture file from the controller.

Step 1 Choose Commands > Upload File to open the Upload File from Controller page (see Figure 7).

Figure 7 Upload File from Controller Page

Step 2 From the File Type drop-down box, choose Packet Capture .

Step 3 From the Transfer Mode drop-down box, choose TFTP or FTP .

Step 4 In the IP Address field, enter the IP address of the TFTP or FTP server.

Step 5 In the File Path field, enter the directory path of the packet capture file.

Step 6 In the File Name field, enter the name of the packet capture file. These files have a .pcap extension.

Step 7 If you are using an FTP server, follow these steps:

a. In the Server Login Username field, enter the username to log into the FTP server.

b. In the Server Login Password field, enter the password to log into the FTP server.

c. In the Server Port Number field, enter the port number on the FTP server through which the upload occurs. The default value is 21.

Step 8 Click Upload to upload the packet capture file from the controller. A message appears indicating the status of the upload.

Step 9 Use Wireshark or another standard packet capture tool to open the packet capture file and see the last 50 packets that were received by the controller.

Using the CLI to Upload Packet Capture Files

Using the controller CLI, follow these steps to upload a packet capture file from the controller.

Step 1 Log into the controller CLI.

Step 2 Enter transfer upload mode {tftp | ftp}.

Step 3 Enter transfer upload datatype packet-capture .

Step 4 Enter transfer upload serverip server-ip-address.

Step 5 Enter transfer upload path server-path-to-file.

Step 6 Enter transfer upload filename last_received_pkts .pcap.

Step 7 If you are using an FTP server, enter these commands:

• transfer upload username username
• transfer upload password password
• transfer upload port port

Note The default value for the port parameter is 21.

Step 8 Enter transfer upload start to view the updated settings; then answer y when prompted to confirm the current settings and start the upload process. This example shows the upload command output:

Step 9 Use Wireshark or another standard packet capture tool to open the packet capture file and see the last 50 packets that were received by the controller.

Diagnostic Channel

The diagnostic channel feature enables you to troubleshoot problems regarding client communication with a WLAN. The client and access points can be put through a defined set of tests in an attempt to identify the cause of communication difficulties the client is experiencing and then allow corrective measures to be taken to make the client operational on the network. You can use the controller GUI or CLI to enable the diagnostic channel, and you can use the controller CLI or WCS to run the diagnostic tests.

Note Cisco recommends that you enable the diagnostic channel feature only for non-anchored SSIDs that use the management interface.

Client Reporting

The client reporting protocol is used by the client and the access point to exchange client information. Client reports are collected automatically when the client associates. You can use the controller GUI or CLI to send a client report request to any CCXv5 client any time after the client associates. There are four types of client reports:

• Client profile—Provides information about the configuration of the client.
• Operating parameters—Provides the details of the client’s current operational modes.
• Manufacturers’ information—Provides data about the wireless LAN client adapter in use.
• Client capabilities—Provides information about the client’s capabilities.

Roaming and Real-Time Diagnostics

You can use roaming and real-time logs and statistics to solve system problems. The event log enables you to identify and track the behavior of a client device. It is especially useful when attempting to diagnose difficulties that a user may be having on a WLAN. The event log provides a log of events and reports them to the access point. There are three categories of event logs:

• Roaming log—This log provides a historical view of the roaming events for a given client. The client maintains a minimum of five previous roaming events including failed attempts and successful roams.
• Robust Security Network Association ( RSNA) log—This log provides a historical view of the authentication events for a given client. The client maintains a minimum of five previous authentication attempts including failed attempts and successful ones.
• Syslog—This log provides internal system information from the client. For example, it may indicate problems with 802.11 operation, system operation, and so on.

The statistics report provides 802.1X and security information for the client. You can use the controller CLI to send the event log and statistics request to any CCXv5 client any time after the client associates.

Using the GUI to Configure the Diagnostic Channel

Follow these steps to configure the diagnostic channel using the controller GUI.

Step 1 Choose WLANs to open the WLANs page.

Step 2 Create a new WLAN or click the ID number of an existing WLAN.

Note Cisco recommends that you create a new WLAN on which to run the diagnostic tests.

Step 3 When the WLANs > Edit page appears, choose the Advanced tab to open the WLANs > Edit (Advanced) page (see Figure 8).

Figure 8 WLANs > Edit (Advanced) Page

Step 4 If you want to enable diagnostic channel troubleshooting on this WLAN, check the Diagnostic Channel check box. Otherwise, leave this check box unchecked, which is the default value.

Note You can use the CLI to initiate diagnostic tests on the client. See the “Using the CLI to Configure the Diagnostic Channel” section for details.

Step 5 Click Apply to commit your changes.

Step 6 Click Save Configuration to save your changes.

Using the CLI to Configure the Diagnostic Channel

Using the controller CLI, follow these steps to configure the diagnostic channel.

Step 1 To enable diagnostic channel troubleshooting on a particular WLAN, enter this command:

config wlan diag-channel { enable | disable } wlan_id

Step 2 To verify that your change has been made, enter this command:

show wlan wlan_id

Information similar to the following appears:

Step 3 To send a request to the client to perform the DHCP test, enter this command:

config client ccx dhcp-test client_mac_address

Note This test does not require the client to use the diagnostic channel.

Step 4 To send a request to the client to perform the default gateway ping test, enter this command:

config client ccx default-gw-ping client_mac_address

Note This test does not require the client to use the diagnostic channel.

Step 5 To send a request to the client to perform the DNS server IP address ping test, enter this command:

config client ccx dns-ping client_mac_address

Note This test does not require the client to use the diagnostic channel.

Step 6 To send a request to the client to perform the DNS name resolution test to the specified host name, enter this command:

config client ccx dns-resolve client_mac_address host_name

Note This test does not require the client to use the diagnostic channel.

Step 7 To send a request to the client to perform the association test, enter this command:

config client ccx test-association client_mac_address ssid bssid { 802.11a | 802.11b | 802.11g } channel

Step 8 To send a request to the client to perform the 802.1X test, enter this command:

config client ccx test-dot1x client_mac_address profile_id bssid { 802.11a | 802.11b | 802.11g } channel

Step 9 To send a request to the client to perform the profile redirect test, enter this command:

config client ccx test-profile client_mac_address profile_id

The profile_id should be from one of the client profiles for which client reporting is enabled.

Note Users are redirected back to the parent WLAN, not to any other profile. The only profile shown is the user’s parent profile. Note however that parent WLAN profiles can have one child diagnostic WLAN.

Step 10 Use these commands if necessary to abort or clear a test:

• To send a request to the client to abort the current test, enter this command:

config client ccx test-abort client_mac_address

Only one test can be pending at a time, so this command aborts the current pending test.

• To clear the test results on the controller, enter this command:

config client ccx clear-results client_mac_address

Step 11 To send a message to the client, enter this command:

config client ccx send-message client_mac_address message_id

where message_id is one of the following:

• 1 = The SSID is invalid.
• 2 = The network settings are invalid.
• 3 = There is a WLAN credibility mismatch.
• 4 = The user credentials are incorrect.
• 5 = Please call support.
• 6 = The problem is resolved.
• 7 = The problem has not been resolved.
• 8 = Please try again later.
• 9 = Please correct the indicated problem.
• 10 = Troubleshooting is refused by the network.
• 11 = Retrieving client reports.
• 12 = Retrieving client logs.
• 13 = Retrieval complete.
• 14 = Beginning association test.
• 15 = Beginning DHCP test.
• 16 = Beginning network connectivity test.
• 17 = Beginning DNS ping test.
• 18 = Beginning name resolution test.
• 19 = Beginning 802.1X authentication test.
• 20 = Redirecting client to a specific profile.
• 21 = Test complete.
• 22 = Test passed.
• 23 = Test failed.
• 24 = Cancel diagnostic channel operation or select a WLAN profile to resume normal operation.
• 25 = Log retrieval refused by the client.
• 26 = Client report retrieval refused by the client.
• 27 = Test request refused by the client.
• 28 = Invalid network (IP) setting.
• 29 = There is a known outage or problem with the network.
• 30 = Scheduled maintenance period.
• 31 = The WLAN security method is not correct.
• 32 = The WLAN encryption method is not correct.
• 33 = The WLAN authentication method is not correct.

Step 12 To see the status of the last test, enter this command:

show client ccx last-test-status client_mac_address

Information similar to the following appears for the default gateway ping test:

Step 13 To see the status of the last test response, enter this command:

show client ccx last-response-status client_mac_address

Information similar to the following appears for the 802.1X authentication test:

Step 14 To see the results from the last successful diagnostics test, enter this command:

show client ccx results client_mac_address

Information similar to the following appears for the 802.1X authentication test:

Step 15 To see the relevant data frames captured by the client during the previous test, enter this command:

show client ccx frame-data client_mac_address

Information similar to the following appears:

Using the GUI to Configure Client Reporting

Follow these steps to configure client reporting using the controller GUI.

Step 1 Choose Monitor > Clients to open the Clients page.

Step 2 Click the MAC address of the desired client. The Clients > Detail page appears (see Figure 9).

Figure 9 Clients > Detail Page

Step 3 To send a report request to the client, click the CCXv5 Req button.

Note You must create a Trusted Profile using ACAU for Cisco CB21AG or equivalent software from your CCXv5 vendor.

Step 4 To view the parameters from the client, click Display . The Client Reporting page appears (see Figure 10).

Figure 10 Client Reporting Page

This page lists the client profiles and indicates if they are currently in use. It also provides information on the client’s operating parameters, manufacturer, and capabilities.

Step 5 Click the link for the desired client profile. The Profile Details page appears (see Figure 11).

Figure 11 Profile Details Page

This page shows the client profile details, including the SSID, power save mode, radio channel, data rates, and 802.11 security settings.

Using the CLI to Configure Client Reporting

Using the controller CLI, follow these steps to configure client reporting.

Step 1 To send a request to the client to send its profiles, enter this command:

config client ccx get-profiles client_mac_address

Step 2 To send a request to the client to send its current operating parameters, enter this command:

config client ccx get-operating-parameters client_mac_address

Step 3 To send a request to the client to send the manufacturer’s information, enter this command:

config client ccx get-manufacturer-info client_mac_address

Step 4 To send a request to the client to send its capability information, enter this command:

config client ccx get-client-capability client_mac_address

Step 5 To clear the client reporting information, enter this command:

config client ccx clear-reports client_mac_address

Step 6 To see the client profiles, enter this command:

show client ccx profiles client_mac_address

Information similar to the following appears:

Step 7 To see the client operating parameters, enter this command:

show client ccx operating-parameters client_mac_address

Information similar to the following appears:

Step 8 To see the client manufacturer information, enter this command:

show client ccx manufacturer-info client_mac_address

Information similar to the following appears:

Step 9 To see the client’s capability information, enter this command:

show client ccx client-capability client_mac_address

Note This command displays the client’s available capabilities, not current settings for the capabilities.

Information similar to the following appears:

Using the CLI to Configure Roaming and Real-Time Diagnostics

Using the controller CLI, follow these steps to configure roaming and real-time diagnostics.

Step 1 To send a log request, enter this command:

config client ccx log-request log_type client_mac_address

where log_type is roam, rsna, or syslog.

Step 2 To view a log response, enter this command:

show client ccx log-response log_type client_mac_address

where log_type is roam, rsna, or syslog.

Information similar to the following appears for a log response with a log_type of roam:

Information similar to the following appears for a log response with a log_type of rsna:

Information similar to the following appears for a log response with a log_type of syslog:

Step 3 To send a request for statistics, enter this command:

config client ccx stats-request measurement_duration stats_name client_mac_address

where stats_name is dot11 or security.

Step 4 To view the statistics response, enter this command:

show client ccx stats-report client_mac_address

Information similar to the following appears:

Prerequisites for Wireless Sniffing

To perform wireless sniffing, you need the following hardware and software:

• A dedicated access point —An access point configured as a sniffer cannot simultaneously provide wireless access service on the network. To avoid disrupting coverage, use an access point that is not part of your existing wireless network.
• A remote monitoring device —A computer capable of running the analyzer software.
• Windows XP or Linux operating system —The controller supports sniffing on both Windows XP and Linux machines.
• Software and supporting files, plug-ins, or adapters —Your analyzer software may require specialized files before you can successfully enable sniffing:

– Omnipeek or Airopeek —Go to WildPackets’ website and follow the instructions to purchase, install, and configure the software.

– AirMagnet—Go to Fluke Networks’ website a nd follow the instructions to purchase, install, and configure the software.

– Wireshark —Go to http://www.wireshark.org/download.html and follow the instructions to download Wireshark and the correct installation wizard for your operating system.

Using the GUI to Configure Sniffing on an Access Point

Using the controller GUI, follow these steps to configure sniffing on an access point.

Step 1 Choose Wireless > Access Points > All APs to open the All APs page.

Step 2 Click the name of the access point that you want to configure as the sniffer. The All APs > Details for page appears (see Figure 14).

Figure 14 All APs > Details for Page

Step 3 From the AP Mode drop-down box, choose Sniffer .

Step 4 Click Apply to commit your changes.

Step 5 Click OK when warned that the access point will be rebooted.

Step 6 Choose Wireless > Access Points > Radios > 802.11a/n (or 802.11b/g/n ) to open the 802.11a/n (or 802.11b/g/n) Radios page.

Step 7 Hover your cursor over the blue drop-down arrow for the desired access point and choose Configure . The 802.11a/n (or 802.11b/g/n) Cisco APs > Configure page appears (see Figure 15).

Figure 15 802.11b/g/n Cisco APs > Configure Page

Step 8 Check the Sniff check box to enable sniffing on this access point, or leave it unchecked to disable sniffing. The default value is unchecked.

Step 9 If you enabled sniffing in Step 8, follow these steps:

a. From the Channel drop-down box, choose the channel on which the access point sniffs for packets.

b. In the Server IP Address field, enter the IP address of the remote machine running Omnipeek, Airopeek, AirMagnet, or Wireshark.

Step 10 Click Apply to commit your changes.

Step 11 Click Save Configuration to save your changes.

Using the CLI to Configure Sniffing on an Access Point

Using the controller CLI, follow these steps to configure sniffing on an access point.

Step 1 To configure the access point as a sniffer, enter this command:

config ap mode sniffer Cisco_AP

where Cisco_AP is the access point configured as the sniffer.

Step 2 When warned that the access point will be rebooted and asked if you want to continue, enter Y . The access point reboots in sniffer mode.

Step 3 To enable sniffing on the access point, enter this command:

config ap sniff {802.11a | 802.11b} enable channel server_IP_address Cisco_AP

where

– channel is the radio channel on which the access point sniffs for packets. The default values are 36 (802.11a/n) and 1 (802.11b/g/n).

– server_IP_address is the IP address of the remote machine running Omnipeek, Airopeek, AirMagnet, or Wireshark.

– Cisco_AP is the access point configured as the sniffer.

Note To disable sniffing on the access point, enter this command:
config ap sniff {802.11a | 802.11b} disable Cisco_AP

Step 4 To save your changes, enter this command:

save config

Step 5 To view the sniffer configuration settings for an access point, enter this command:

show ap config {802.11a | 802.11b} Cisco_AP

Information similar to the following appears:

Using the GUI to Troubleshoot Access Points Using Telnet or SSH

Using the controller GUI, follow these steps to enable Telnet or SSH access (or both) on lightweight access points.

Step 1 Choose Wireless > Access Points > All APs to open the All APs page.

Step 2 Click the name of the access point for which you want to enable Telnet or SSH.

Step 3 Choose the Advanced tab to open the All APs > Details for (Advanced) page (see Figure 16).

Figure 16 All APs > Details for (Advanced) Page

Step 4 To enable Telnet connectivity on this access point, check the Telnet check box. The default value is unchecked.

Step 5 To enable SSH connectivity on this access point, check the SSH check box. The default value is unchecked.

Step 6 Click Apply to commit your changes.

Step 7 Click Save Configuration to save your changes.

Using the CLI to Troubleshoot Access Points Using Telnet or SSH

Using the controller CLI, follow these steps to enable Telnet or SSH access (or both) on lightweight access points.

Step 1 To enable Telnet or SSH connectivity on an access point, enter this command:

config ap {telnet | ssh} enable Cisco_AP

The default value is disabled.

Note To disable Telnet or SSH connectivity on an access point, enter this command:
config ap {telnet | ssh} disable Cisco_AP

Step 2 To save your changes, enter this command:

save config

Step 3 To see whether Telnet or SSH is enabled on an access point, enter this command:

show ap config general Cisco_AP

Information similar to the following appears:

Using the CLI to Debug Access Point Monitor Service Issues

If you experience any problems with the access point monitor service, enter this command:

debug service ap-monitor { all | error | event | nmsp | packet } { enable | disable }

where

• all configures debugging of all access point status messages,
• error configures debugging of access point monitor error events,
• event configures debugging of access point monitor events,
• nmsp configures debugging of access point monitor NMSP events, and
• packet configures debugging of access point monitor packets.

Interpreting OfficeExtend LEDs

The LED patterns are different for 1130 series and 1140 series OfficeExtend access points. Refer to the Cisco OfficeExtend Access Point Quick Start Guide for a description of the LED patterns.

Positioning OfficeExtend Access Points for Optimal RF Coverage

When positioning your OfficeExtend access point, consider that its RF signals are emitted in a cone shape spreading outward from the LED side of the access point (see Figure 17). Be sure to mount the access point so that air can flow behind the metal back plate and prevent the access point from over heating.

Figure 17 OfficeExtend Access Point Radiation Patterns

Troubleshooting Common Problems

Most of the problems experienced with OfficeExtend access points are one of the following:

• The access point cannot join the controller because of network or firewall issues.

Resolution: Follow the instructions in the “Viewing Access Point Join Information” section to view join statistics for the OfficeExtend access point, or find the access point’s public IP address and perform pings of different packet sizes from inside the company.

• The access point joins but keeps dropping off. This behavior usually occurs because of network problems or when the network address translation (NAT) or firewall ports close because of short timeouts.

Resolution: Ask the teleworker for the LED status.

• Clients cannot associate because of NAT issues.

Resolution: Ask the teleworker to perform a speed test and a ping test in DSL Reports website. Some servers do not return big packet pings, so use the www.dslreports.com server to do pings such as ping -l 1500 -n 10 www.dslreports.com.

• Clients keep dropping data. This behavior usually occurs because the home router closes the port because of short timeouts.

Resolution: Perform client troubleshooting in WCS to determine if the problem is related to the OfficeExtend access point or the client.

• The access point is not broadcasting the enterprise WLAN.

Resolution: Ask the teleworker to check the cables, power supply, and LED status. If you still cannot identify the problem, ask the teleworker to try the following:

– Connect to the home router directly and see if the PC is able to connect to an Internet website such as http://www.cisco.com/ . If the PC cannot connect to the Internet, check the router or modem. If the PC can connect to the Internet, check the home router configuration to see if a firewall or MAC-based filter is enabled that is blocking the access point from reaching the Internet.

– Log into the home router and check to see if the access point has obtained an IP address. If it has, the access point’s LED normally blinks orange.

• The access point cannot join the controller, and you cannot identify the problem.

Resolution: A problem could exist with the home router. Ask the teleworker to check the router manual and try the following:

– Assign the access point a static IP address based on the access point’s MAC address.

– Put the access point in a demilitarized zone (DMZ), which is a small network inserted as a neutral zone between a company’s private network and the outside public network. It prevents outside users from getting direct access to a server that has company data.

– If problems still occur, contact your company’s IT department for assistance.

• The teleworker experiences problems while configuring a personal SSID on the access point.

Resolution: Clear the access point configuration and return it to factory default settings by clicking Clear Config on the access point GUI or by entering this command on the controller CLI: clear ap config Cisco_AP, and then follow the steps in the “Configuring a Personal SSID on an OfficeExtend Access Point” section to try again. If problems still occur, contact your company’s IT department for assistance.

• The home network needs to be rebooted.

Resolution: Ask the teleworker to follow these steps:

a. Leave all devices networked and connected; then power down all the devices.

b. Turn on the cable or DSL modem; then wait for 2 minutes. (Check the LED status.)

c. Turn on the home router; then wait for 2 minutes. (Check the LED status.)

d. Turn on the access point; then wait for 5 minutes. (Check the LED status.)

e. Turn on the client.