Fortinet Document Library

Version:

Version:


Table of Contents

FortiWiFi and FortiAP Configuration Guide

Download PDF
Copy Link

Troubleshooting

To troubleshoot the FortiOS wireless controller and FortiAP units, this section includes the following topics:

FortiAP shell command

The FortiAP is often behind a NAT device and access to the FortiAP through SSH is not available. The FortiGate WiFi controller can send a FortiAP shell command (up to 127 bytes) to the FortiAP. The FortiAP runs this command and then returns the results to the controller using the Control and Provisioning of Wireless Access Points Protocol (CAPWAP) tunnel.

The maximum output from a FortiAP shell command is limited to 4 MB. The default output size is set to 32 KB.

The FortiAP reports the running results to the controller after the command is finished. If the controller sends a new command to the FortiAP before the previous command is finished, the previous command is canceled.

Enter the following command:

diag w-c wlac wtpcmd wtp_ip wtp_port cmd [cmd-to-ap] cmd: run,show,showhex,clr,r&h,r&sh

  • cmd-to-ap: any shell commands, but FortiAP does not report results until the command is finished on the FortiAP
  • run: controller sends the ap-cmd to the FortiAP to run
  • show: show current results reported by the FortiAP in text
  • showhex: show current results reported by the FortiAP in hexadecimal format.
  • clr: clear reported results
  • r&s: run and show
  • r&sh: run and show in hexadecimal format

Signal strength issues

This section includes information to help you identify and troubleshoot poor signal strength issues.

Asymmetric power issue

Asymmetric power issues are a typical problem in wireless communications. Access points (AP) can have a high transmit power which means that a signal can travel a long distance. However, clients may not have a transmit power strong enough for the APs to detect their signal.

Measuring signal strength in both directions

To solve an asymmetric power issue, measure the signal strength in both directions. APs usually have enough power to transmit long distances, but sometimes battery-powered clients have a reply signal that has less power, and therefore the AP cannot detect their signal.

It is recommended that you match the transmission power of the AP to the least powerful wireless client—around 10 decibels per milliwatt (dBm) for iPhones and 14 dBm for most laptops.

Even if the signal is strong enough, other devices may also emit radiation and cause interference. To identify the difference, read the client Rx strength from the FortiGate GUI (under Monitor > WiFi Client Monitor) or CLI.

The Signal Strength/Noise value provides the received signal strength indicator (RSSI) of the wireless client. For example, a value of -85 dBm to -95 dBm is equal to about 10 dB levels; this is not a desirable signal strength. In the following screenshot, one of the clients is at 18 dB, which is getting close to the perimeter of its range.

note icon

The recommended Signal Strength/Noise value from and to the FortiAP by clients is in the range of -20 dBm to -65 dBm.

You can also confirm the transmission (Tx) power of the controller on the AP profile (wtp-profile) and the FortiAP (iwconfig), and check the power management (auto-Tx) options.

Controller configured transmitting power - CLI:

config wireless-controller wtp-profile

config <radio>

show

(the following output is limited to power levels)

auto-power-level : enable

auto-power-high : 17

auto-power-low : 10

Actual FortiAP transmitting power - CLI:

iwconfig wlan00

Result:

wlan00      IEEE 802.11ng   ESSID:"signal-check"

Mode:Master Frequency:2.412 GHz    Access Point:<MAC add>

Bit Rate:130 Mb/s   Tx-Power=28 dBm

 

Using FortiPlanner

The most thorough method to solve signal strength issues is to perform a site survey using FortiPlanner.

For details about FortiPlanner, visit the FortiPlanner website. You can download FortiPlanner here.

Sample depiction of a site survey using FortiPlanner

The site survey helps with the optimal placement for your APs based on the variables in your environment. You must provide the site survey detailed information such as a floor plan (to scale) and structural materials. FortiPlanner allows you to place the APs on the map and adjust the radio bands and power levels while providing you with visual wireless coverage.

The following list includes mechanisms for gathering further information on the client for Rx strength. The goal is to see how well the client is receiving the signal from the AP. You can also verify FortiAP signal strength on the client using WiFi client utilities, or third-party utilities such as InSSIDer or MetaGeek Chanalyzer.

  • Professional Site Survey software (Ekahau, AirMagnet survey Pro, FortiPlanner)
  • InSSIDer
  • On Windows: “netsh wlan show networks mode=bssid” (look for the BSSID, it's in % not in dBm)
  • On MacOS: Use the “airport” command:

“/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport” airport –s | grep <the_bssid> (live scan each time)

  • On Android: WiFiFoFum

Frequency interference

If the wireless signal seems to be strong but then periodically drops, this may be a symptom of frequency interference. Frequency interference is when another device also emits radio frequency using the same channel, co-channel, or adjacent channel, thereby overpowering or corrupting your signal. This is a common problem on a 2.4 GHz network.

There are two types of interference: coherent and non-coherent.

  • Coherent interference is a result of another device using the same channel as your AP, or poor planning of a wireless infrastructure. Perhaps the other nearby APs are using the same channel or the signal strength is too high.
  • Non-coherent interference is a result of other radio signals such as Bluetooth, microwave, cordless phone, or x-ray machines (as in medical environments).

The most common and simple solution for frequency interference is to change your operation channel. Typically, the channel can be set from 1 to 11 for the broadcast frequency, although it is recommended to use channels 1, 6, and 11 on the 2.4 GHz band.

Another solution, if it is appropriate for your location, is to use the 5 GHz band instead.

MetaGeek Chanalyzer

You can perform a site survey using spectrum analysis at various points in your environment to locate sources of interference. MetaGeek Chanalyzer is an example of a third-party utility used for spectrum analysis of complex WiFi networks.

Fortinet wireless adapters ignore signals of -95 dBm or less.

 

Throughput issues

Topics in this section help you identify throughput issues to suggest actions to address them.

Link testing

You can identify delays or lost packets by sending ping packets from your wireless client. If there is more than 10 ms of delay, there may be a problem with your wireless deployment, such as:

  • The client transmits a week signal. The host does not reach the AP.
  • The AP utilization is too high. Your AP is saturated with connected clients.
  • There is interference in the wireless network. Third-party signal can degrade your AP or the client's ability to detect signals between them.
  • The AP has a weak transmit power. The AP does not reach the host. This problem is not common in a properly deployed network, unless the client is too far away.

Performance testing

If the FortiAP gives poor throughput to the client, the link can drop. You can measure the link throughput or performance between two devices by using third-party application tools such as iPerf and jPerf.

Measuring the file transfer speed

Another way to get a sense of your throughput issues is to measure the speed of a file transfer on your network. Create a test file at a specific size and measure the speed at which Windows measures the transfer. The command below creates a 50 MB file. The file name is test.txt.

  • fsutil file createnew test.txt 52428800

The following image shows a network transfer speed of just over 24 Mbps. The theoretical speed of 802.11g is 54 Mbps, which is what this client is using. A wireless client is never likely to see the theoretical speed.

TKIP limitation

If you find that throughput is a problem, avoid WPA security encrypted with Temporal Key Integrity Protocol (TKIP) as it supports communications only at 54 Mbps. Use WPA-2 AES instead.

Speeds are very much based on what the client computer can handle as well. The maximum client connection rate of 130 Mbps is for 2.4 GHz on a 2x2, or 300 Mbps for 5 GHz on a 2x2 (using shortguard and channel bonding enabled).

If you want to get more than 54 Mbps with 802.11n, do not use legacy TKIP, use CCMP instead. This is standard for legacy compatibility.

IP packet fragmentation prevention in CAPWAP tunnels

TKIP is not the only possible source of decreased throughput. When a wireless client sends jumbo frames using a CAPWAP tunnel, it can result in data loss, jitter, and decreased throughput. For more details, see IP fragmentation of packets in CAPWAP tunnels.

Slow DTLS response

The following elements are involved in the CAPWAP association:

  • request
  • response
  • full of DTLS (Datagram Transport Layer Security) tunnel establishment
  • join
  • configuration

All of these element are bidirectional. If the DTLS response is slow, there could be a configuration error or an issue with a certificate during the discovery response. For details about the CAPWAP Protocol Specification, see RFC 5415 and RFC 5416.

Client connection issues

  1. If the client is unable to connect to FortiAP:
    • Make sure the client security and authentication settings match with FortiAP and also check the certificates.
    • Try upgrading the Wi-Fi adapter driver, FortiGate and FortiAP firmware.
    • If other clients can connect, the issue can be with device interoperability. Run debug commands and sniffer packets.
    • Look for rogue suppression by sniffing the wireless traffic and looking for the connection issue in the output (using the AP or wireless packet sniffer).
    • Try changing the IEEE protocol from 802.11n to 802.11bg or 802.11a only.
  2. If the client drops and reconnects:
    • The client might be de-authenticating periodically. Check the sleep mode on the client.
    • The issue could be related to power-saver settings. The client may need to update the drivers.
    • The issue could also be caused by flapping between APs. Check the roaming sensitivity settings on the client or the preferred wireless network settings on the client. If another WiFi network is available, the client may connect to it if it is a preferred network. Also, check the DHCP configuration as this configuration may be an IP conflict.
  3. If the client drops and never connects:
    • The client could have roamed to another SSID. Check the standby and sleep modes.
    • You may need to bring the interface up and down.
  4. If the client connects, but no IP address is acquired by the client:
    • Check the DHCP configuration and the network.
    • There could be a broadcast issue. Check the WEP encryption key and set a static IP address and VLANs.

Debugging client connection issues

To see the stage at which the client fails to connect, enable the client debug on the controller for problematic clients. Try to connect from the problematic client and run the following debug command, which allows you to see the four-way handshake of the client association:

diagnose wireless-controller wlac sta_filter <client MAC address> 2

Example of a successful client connection:

The following example debug output is for the above command. This example shows the successful association phase, DHCP phase, and the PSK key exchange (identified in color):

FG600B3909600253 #

91155.197 <ih> IEEE 802.11 mgmt::assoc_req <== 30:46:9a:f9:fa:34 vap signal-check rId 0 wId 0 00:09:0f:f3:20:45

91155.197 <ih> IEEE 802.11 mgmt::assoc_resp ==> 30:46:9a:f9:fa:34 vap signal-check rId 0 wId 0 00:09:0f:f3:20:45 resp 0

91155.197 <cc> STA_CFG_REQ(15) sta 30:46:9a:f9:fa:34 add ==> ws (0-192.168.35.1:5246) rId 0 wId 0

91155.197 <dc> STA add 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 bssid 00:09:0f:f3:20:45 NON-AUTH

91155.197 <cc> STA add 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45 sec WPA2 AUTO auth 0

91155.199 <cc> STA_CFG_RESP(15) 30:46:9a:f9:fa:34 <== ws (0-192.168.35.1:5246) rc 0 (Success)

91155.199 <eh> send 1/4 msg of 4-Way Handshake

91155.199 <eh>send IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=95 replay cnt 1

91155.199 <eh> IEEE 802.1X (EAPOL 99B) ==> 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45

91155.217 <eh> IEEE 802.1X (EAPOL 121B) <== 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45

91155.217 <eh> recv IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=117

91155.217 <eh> recv EAPOL-Key 2/4 Pairwise replay cnt 1

91155.218 <eh> send 3/4 msg of 4-Way Handshake

91155.218 <eh> send IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=175 replay cnt 2

91155.218 <eh> IEEE 802.1X (EAPOL 179B) ==> 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45

91155.223 <eh> IEEE 802.1X (EAPOL 99B) <== 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45

91155.223 <eh> recv IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=95

91155.223 <eh> recv EAPOL-Key 4/4 Pairwise replay cnt 2

91155.223 <dc> STA chg 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 bssid 00:09:0f:f3:20:45 AUTH

91155.224 <cc> STA chg 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45 sec WPA2 AUTO auth 1

91155.224 <cc> STA_CFG_REQ(16) sta 30:46:9a:f9:fa:34 add key (len=16) ==> ws (0-192.168.35.1:5246) rId 0 wId 0

91155.226 <cc> STA_CFG_RESP(16) 30:46:9a:f9:fa:34 <== ws (0-192.168.35.1:5246) rc 0 (Success)

91155.226 <eh> ***pairwise key handshake completed*** (RSN)

91155.257 <dc> DHCP Request server 0.0.0.0 <== host ADMINFO-FD4I2HK mac 30:46:9a:f9:fa:34 ip 172.16.1.16

91155.258 <dc> DHCP Ack server 172.16.1.1 ==> host mac 30:46:9a:f9:fa:34 ip 172.16.1.16 mask 255.255.255.0 gw 172.16.1.1

 

where:

  • Orange represents the association phase.
  • Blue represents the PSK exchange.
  • Green represents the DHCP phase.

It is important to note the messages for a correct association phase, four-way handshake, and DHCP phase.

Checking the WiFi password

An Administrator can view plain text passwords (captive-portal-radius-secret and passphrase) under config wireless-controller vap.

Note that security must be set as a WPA-personal setting.

FortiAP connection issues

A communication problem can arise from the FortiAP.

Some examples include:

  • The FortiAP is not connecting to the wireless controller.
  • One FortiAP intermittently disconnects and re-connects.
  • All FortiAPs intermittently disconnect and re-connect.

In the above cases:

  • Check networking on the distribution system for all related FortiAPs.
  • Check the authorization status of managed APs from the wireless controller.
  • Restart the cw_acd process.

    Note: A restart of the cw_acd process drops all APs.

  • For any wireless controller daemon crashes, check the controller crash log using the following command:
  • diagnose debug crashlog read

Debugging FortiAP connection issues

For a quick assessment of the association communication between the controller and the FortiAP, run the following sniffer command to see if you can verify that the AP is communicating to the controller by identifying the CAPWAP communication:

diagnose sniff packet <interface_name> “port 5246” 4

 

If you do not see this communication, then you can investigate the network or the settings on the AP to see why it is not reaching the controller.

To collect verbose output from the sniff that can be converted to a PCAP and viewed in Wireshark, use the following command:

diagnose sniff packet <interface_name> “port 5246” 6 0 l

 

The image below shows the beginning of the AP association to the controller. You can see the discovery Request and Response at the top.

Throughout debugging it is recommended to:

  • Enable SSH login to the FortiAP device so that you can log in and issue local debugging commands:

config wireless-controller wtp

edit "<FortiAP_serial_number>"

set override-allowaccess {disable|enable}

set allowaccess {https | ssh}

end

 

  • Try to connect to the wireless controller from the problematic FortiAP to verify routes exist.
  • Enable wtp (FortiAP) debugging on the wireless controller for problematic FortiAPs to determine the point at which the FortiAP fails to connect:

diag wireless-controller wlac wtp_filter FP112B3X13000193 0-192.168.6.8:5246 2

(replace the serial number and IP address of the FortiAP)

di de console timestamp en

di de application cw_acd 0x7ff

di de en

Example of a successful AP and controller association:

Here is another example of a successful association between the FortiAP and the wireless controller. This example includes elements of the CAPWAP protocol; Request, Response, DTLS, Join, and Configuration (identified in color). All of these elements are bi-directional. So, if the DTLS response is slow, there could be a configuration error.

56704.575 <msg> DISCOVERY_REQ (12) <== ws (0-192.168.35.1:5246)

56704.575 <msg> DISCOVERY_RESP (12) ==> ws (0-192.168.35.1:5246)

56707.575 <msg> DISCOVERY_REQ (13) <== ws (0-192.168.35.1:5246)

56707.575 <msg> DISCOVERY_RESP (13) ==> ws (0-192.168.35.1:5246)

56709.577 <aev> - CWAE_INIT_COMPLETE ws (0-192.168.35.1:5246)

56709.577 <aev> - CWAE_LISTENER_THREAD_READY ws (0-192.168.35.1:5246)

56709.577 <fsm> old CWAS_START(0) ev CWAE_INIT_COMPLETE(0) new CWAS_IDLE(1)

56709.577 <fsm> old CWAS_IDLE(1) ev CWAE_LISTENER_THREAD_READY(1) new CWAS_DTLS_SETUP(4)

56709.623 <aev> - CWAE_DTLS_PEER_ID_RECV ws (0-192.168.35.1:5246)

56709.623 <aev> - CWAE_DTLS_AUTH_PASS ws (0-192.168.35.1:5246)

56709.623 <aev> - CWAE_DTLS_ESTABLISHED ws (0-192.168.35.1:5246)

56709.623 <fsm> old CWAS_DTLS_SETUP(4) ev CWAE_DTLS_PEER_ID_RECV(7) new CWAS_DTLS_AUTHORIZE(2)

56709.623 <fsm> old CWAS_DTLS_AUTHORIZE(2) ev CWAE_DTLS_AUTH_PASS(3) new CWAS_DTLS_CONN(5)

56709.623 <fsm> old CWAS_DTLS_CONN(5) ev CWAE_DTLS_ESTABLISHED(8) new CWAS_JOIN(7)

56709.625 <msg> JOIN_REQ (14) <== ws (0-192.168.35.1:5246)

56709.625 <aev> - CWAE_JOIN_REQ_RECV ws (0-192.168.35.1:5246)

56709.626 <fsm> old CWAS_JOIN(7) ev CWAE_JOIN_REQ_RECV(12) new CWAS_JOIN(7)

56709.629 <msg> CFG_STATUS (15) <== ws (0-192.168.35.1:5246)

56709.629 <aev> - CWAE_CFG_STATUS_REQ ws (0-192.168.35.1:5246)

56709.629 <fsm> old CWAS_JOIN(7) ev CWAE_CFG_STATUS_REQ(13) new CWAS_CONFIG(8)

56710.178 <msg> CHG_STATE_EVENT_REQ (16) <== ws (0-192.168.35.1:5246)

56710.178 <aev> - CWAE_CHG_STATE_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.178 <fsm> old CWAS_CONFIG(8) ev CWAE_CHG_STATE_EVENT_REQ_RECV(23) new CWAS_DATA_CHAN_SETUP(10)

56710.220 <aev> - CWAE_DATA_CHAN_CONNECTED ws (0-192.168.35.1:5246)

56710.220 <msg> DATA_CHAN_KEEP_ALIVE <== ws (0-192.168.35.1:5246)

56710.220 <aev> - CWAE_DATA_CHAN_KEEP_ALIVE_RECV ws (0-192.168.35.1:5246)

56710.220 <msg> DATA_CHAN_KEEP_ALIVE ==> ws (0-192.168.35.1:5246)

56710.220 <fsm> old CWAS_DATA_CHAN_SETUP(10) ev CWAE_DATA_CHAN_CONNECTED(32) new CWAS_DATA_CHECK(11)

56710.220 <aev> - CWAE_DATA_CHAN_VERIFIED ws (0-192.168.35.1:5246)

56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_KEEP_ALIVE_RECV(35) new CWAS_DATA_CHECK(11)

56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_VERIFIED(36) new CWAS_RUN(12)

56710.228 <msg> WTP_EVENT_REQ (17) <== ws (0-192.168.35.1:5246)

56710.228 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.228 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56710.230 <msg> CFG_UPDATE_RESP (1) <== ws (0-192.168.35.1:5246) rc 0 (Success)

56710.230 <aev> - CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)

56710.230 <msg> WTP_EVENT_REQ (18) <== ws (0-192.168.35.1:5246)

56710.230 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.230 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)

56710.230 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56710.231 <msg> WTP_EVENT_REQ (19) <== ws (0-192.168.35.1:5246)

56710.231 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.231 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56710.232 <msg> CFG_UPDATE_RESP (2) <== ws (0-192.168.35.1:5246) rc 0 (Success)

56710.232 <aev> - CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)

56710.232 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)

56710.233 <msg> WTP_EVENT_REQ (20) <== ws (0-192.168.35.1:5246)

56710.233 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.233 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56712.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 3 dbg 00000000 pkts 12493 0

56715.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 6 dbg 00000000 pkts 12493 0

56718.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 9 dbg 00000000 pkts 12493 0

56719.253 <aev> - CWAE_AC_ECHO_INTV_TMR_EXPIRE ws (0-192.168.35.1:5246)

56719.253 <fsm> old CWAS_RUN(12) ev CWAE_AC_ECHO_INTV_TMR_EXPIRE(39) new CWAS_RUN(12)

56719.576 <msg> ECHO_REQ (21) <== ws (0-192.168.35.1:5246)

56719.576 <aev> - CWAE_ECHO_REQ_RECV ws (0-192.168.35.1:5246)

56719.577 <fsm> old CWAS_RUN(12) ev CWAE_ECHO_REQ_RECV(27) new CWAS_RUN(12)

 

where:

  • Orange represents the Discovery phase.
  • Blue indicates that the control channels have been established using DTLS.
  • Green represents the access point Discovery and Join phase.
  • Purple represents the Clear Text channel.
  • Pink indicates that the FortiAP is successfully connected to the wireless controller.

Best practices for OSI common sources of wireless issues

Not all WiFi problems are related to signal strength, interference, or misconfiguration. The following OSI model identifies some of the more common issues per layer.

Best practices for troubleshooting vary depending on the affected layer. See the following illustration.

Common sources of wireless issues

 

Best practices for Layer 1

Common physical layer issues include:

  • weak received signal
  • WiFi capability: 802.11b, 1x1, 2x2
  • co-channel WiFi interference
  • side band WiFi interference
  • non 802.11 noise (such as microwave ovens)

To avoid physical layer issues:

  • Determine the RST (Receiver Sensitivity Threshold) for your device, or use -70 dBm as a rule of thumb.
  • Match the AP TX output power to the client TX output power.
  • Use DFS (Dynamic Frequency Selection) for high performance data 20/40 MHz.
  • Use 5 GHz UNII-1 & 3 (Non-DFS) bands with static channel assignment for latency-sensitive applications.
  • Do not use 40 MHz channels in 2.4 GHz band. (FortiOS does not allow channel bonding.)

Best practices for Layer 2

Common data link (MAC) layer issues include:

  • too many clients on a single channel (CSMA/CA) backoff
  • too many high-priority traffic clients (WMM)
  • incorrect password or encryption settings
  • too many beacons (in high-density installations)

To avoid data link layer issues:

  • Only use CCMP/AES (WPA2) encryption (not TKIP).
  • In high-density deployments, turn off SSID broadcast or turn down SSID rates. Review and possibly reduce the beacon interval.
  • Determine the best cell size for applications:
    • For few users and low bandwidth latency sensitive applications, use high-transmit power to create larger cells.
    • For high-performance and high-capacity installations, use lower transmit power to create smaller cells (set FortiPlanner at 10 dBm TX power), but bear in mind that this setting requires more roaming.

Cells and co-channel interference

In high-density deployments, multiple APs are used, and each one services an area called a cell. However, these cells can cause interference with each other. This is a common problem. The radio signal from one AP interferes with, or cancels out, the radio signal from another AP.

In the following diagram, note the interference zone created by one radio, causing interference on its neighboring APs.

The interference zone can be twice the radius of the signal, and the signal at its edge can be -67 dBm.

Reducing co-channel interference

For best results, use a honeycomb pattern as a deployment strategy. The idea is to stagger repeated channels furthest from each other to avoid interference.

Best practices for Layer 3 and above

For TCP/IP layers and above, a common source of latency, or slowness in the wireless traffic, is too many broadcasts or multicasts. These types of issues can result from non-business or unwanted traffic, or both.

To resolve issues at the TCP/IP layer and above, you can:

  • identify business-critical applications
  • use Application Control, Web Filtering, Traffic Shaping, and QoS to prioritize applications
    • Identify unwanted traffic, high-bandwidth web-related traffic, and use Security Profiles.
    • Use the traffic shaping on a policy to rate-limit this traffic.
  • You perform these configurations directly on the FortiGate.

Packet sniffer

Capturing the traffic between the controller and the FortiAP can help you identify most FortiAP and client connection issues.

CAPWAP packet sniffer

The first recommended technique consists of sniffing the CAPWAP traffic.

  • Enable plain control on the controller and on the FortiAP to capture clear control traffic on UDP port 5246.
    • On the controller:

    diagnose wireless-controller wlac plain-ctl <FortiAP_serial_number> 1

    Result:

    WTP 0-FortiAP2223X11000107 Plain Control: enabled

    • On the FortiAP:

    cw_diag plain-ctl 1

    Result:

    Current Plain Control: enabled

Note that some issues are related to the keep-alive for control and data channel.

Data traffic on UDP port 5247 is not encrypted. The data itself is encrypted by the wireless security mechanism.

Data traffic is helpful to troubleshoot most of the issues related to station association, EAP authentication, WPA key exchange, roaming, and FortiAP configuration.

You can also set up a host or server to which you can forward the CAPWAP traffic:

  1. Configure the host or server to which CAPWAP traffic is forwarded:

    diagnose wireless-controller wlac sniff-cfg <Host_IP_address> 88888

    Result:

    Current Sniff Server: 192.168.25.41, 23352

  2. Choose which traffic to capture, the interface to which the FortiAP is connected, and the FortiAP serial number:

    diagnose wireless-controller wlac sniff <interface_name> <FortiAP_serial_number> 2

    Result:

    WTP 0-FortiAP2223X11000107 Sniff: intf port2 enabled (control and data message)

    In the above syntax, the '2' captures the control and data message. The '1' would capture only the control message and '0' would disable it.

  3. Run Wireshark on the host or server to capture CAPWAP traffic from the controller.
  4. Decode the traffic as IP to check inner CAPWAP traffic.
Example CAPWAP packet capture

The following image shows an example of a CAPWAP packet capture, where you can see the following details:

  • Layer 2 header
  • sniffed traffic encapsulated into Internet Protocol for transport
  • CAPWAP encapsulated into UDP for sniffer purpose and encapsulated into IP
  • CAPWAP control traffic on UDP port 5246
  • CAPWAP payload

Wireless traffic packet sniffer

The second recommended technique consists of sniffing the wireless traffic directly on the air using your FortiAP.

Wireless traffic packet capture

Packet captures are useful for troubleshooting all wireless client related issues because you can verify data rate and 802.11 parameters, such as radio capabilities, and determine issues with wireless signal strength, interference, or congestion on the network.

A radio can only capture one frequency at a time; one of the radios is set to sniffer mode depending on the traffic or channel required. You must use two FortiAPs to capture both frequencies at the same time.

  • Set a radio on the FortiAP to monitor mode.

    iwconfig wlan10

     

    Result:

    wlan10    IEEE 802.11na     ESSID:""

    Mode:Monitor  Frequency:5.18 GHz  Access Point: Not-Associated

 

  • The capture file is stored under the temp directory as wl_sniff.pcap

    /tmp/wl_sniff.cap

  • Remember that the capture file is only stored temporarily. If you want to save it, upload it to a TFTP server before rebooting or changing the radio settings.
  • The command cp wl_sniff.cap newname.pcap allows you to rename the file.
  • Rather than TFTP the file, you can also log in to the AP and retrieve the file via the web interface. Move the file using the command: mv name /usr/www.

    You can verify that the file was moved using the command cd/usr/www and then browsing to: <fortiAP_IP>/filename.

Syntax

The following syntax demonstrates how to set the radio to sniffer mode (configurable from the CLI only). Sniffer mode provides options to filter for specific traffic to capture. Notice that you can determine the buffer size, which channel to sniff, the AP MAC address, and select if you want to sniff the beacons, probes, controls, and data channels.

configure wireless-controller wtp-profile

edit <profile_name>

configure <radio>

set mode sniffer

set ap-sniffer-bufsize 32

set ap-sniffer-chan 1

set ap-sniffer-addr 00:00:00:00:00:00

set ap-sniffer-mgmt-beacon enable

set ap-sniffer-mgmt-probe enable

set ap-sniffer-mgmt-other enable

set ap-sniffer-ctl enable

set ap-sniffer-data enable

end

end

 

Once you have performed the previous CLI configuration, you can see the packet sniffer mode selected in the GUI dashboard under WiFi & Switch Controller > FortiAP Profiles and WiFi & Switch Controller > Managed FortiAPs. Bear in mind that if you change the mode from the GUI, you need to return to the CLI to re-enable the sniffer mode.

To disable the sniffer profile in the CLI, use the following commands:

config wireless-controller wtp-profile

edit <profile_name>

config <radio>

set ap-sniffer-mgmt-beacon disable

set ap-sniffer-mgmt-probe disable

set ap-sniffer-mgmt-other disable

set ap-sniffer-ctl disable

set ap-sniffer-data disable

end

end

 

 

If you change the radio mode before sending the file wl_sniff.cap to an external TFTP, the file is deleted and you lose your packet capture.

Example AP packet capture

The following image shows an example of the AP packet capture with the following details:

  • capture header showing channel 36
  • beacon frame
  • source, destination, and BSSID of the beacon frame
  • SSID of the beacon frame

Debug commands

For a list of debug options available for the wireless controller, use the following command on the controller:

diagnose wireless-controller wlac help

Sample outputs

Syntax

diagnose wireless-controller wlac -c vap

(This command lists the information about the virtual access point, including its MAC address, the BSSID, its SSID, the interface name, and the IP address of the APs that are broadcasting it.)

 

Result:

bssid              ssid      intf        vfid:ip-port rId wId

00:09:0f:d6:cb:12 Office Office    ws (0-192.168.3.33:5246) 0 0

00:09:0f:e6:6b:12 Office Office    ws (0-192.168.1.61:5246) 0 0

06:0e:8e:27:dc:48 Office Office   ws (0-192.168.3.36:5246) 0 0

0a:09:0f:d6:cb:12 public publicAP ws (0-192.168.3.33:5246) 0 1

 

Syntax

diagnose wireless-controller wlac -c darrp

(This command lists the information pertaining to the radio resource provisioning statistics, including the AP serial number, the number of channels set to choose from, and the operation channel. Note that the 5 GHz band is not available on these APs listed.)

 

Result:

wtp_id           rId  base_mac          index       nr_chan vfid 5G oper_chan age

FAP22A3U10600400 0    00:09:0f:d6:cb:12 0                3       0               No 1                                          87588

FW80CM3910601176 0    06:0e:8e:27:dc:48 1     3       0    No 6         822

 

Extension information support

You can enable or disable extension information at wtp-profile, and use the diagnose option below to print out the detail of extension information.

Syntax

config wireless-controller wtp-profile

edit test

set lldp [enable | disable]

set ext-info-enable

[enable | disable] --> Enable or disable station, VAP, and radio extension information.

end

end

 

diagnose wireless-controller wlac -d [wtp | vap | sta]

 

where:

  • wlac -d wtp [SN|name] [reset] --> List or reset wtp info (data).
  • wlac -d vap [bssid] [reset] --> List or reset vap info (data). .
  • wlac -d sta [mac] [reset] --> list or reset sta info (data).

Troubleshooting

To troubleshoot the FortiOS wireless controller and FortiAP units, this section includes the following topics:

FortiAP shell command

The FortiAP is often behind a NAT device and access to the FortiAP through SSH is not available. The FortiGate WiFi controller can send a FortiAP shell command (up to 127 bytes) to the FortiAP. The FortiAP runs this command and then returns the results to the controller using the Control and Provisioning of Wireless Access Points Protocol (CAPWAP) tunnel.

The maximum output from a FortiAP shell command is limited to 4 MB. The default output size is set to 32 KB.

The FortiAP reports the running results to the controller after the command is finished. If the controller sends a new command to the FortiAP before the previous command is finished, the previous command is canceled.

Enter the following command:

diag w-c wlac wtpcmd wtp_ip wtp_port cmd [cmd-to-ap] cmd: run,show,showhex,clr,r&h,r&sh

  • cmd-to-ap: any shell commands, but FortiAP does not report results until the command is finished on the FortiAP
  • run: controller sends the ap-cmd to the FortiAP to run
  • show: show current results reported by the FortiAP in text
  • showhex: show current results reported by the FortiAP in hexadecimal format.
  • clr: clear reported results
  • r&s: run and show
  • r&sh: run and show in hexadecimal format

Signal strength issues

This section includes information to help you identify and troubleshoot poor signal strength issues.

Asymmetric power issue

Asymmetric power issues are a typical problem in wireless communications. Access points (AP) can have a high transmit power which means that a signal can travel a long distance. However, clients may not have a transmit power strong enough for the APs to detect their signal.

Measuring signal strength in both directions

To solve an asymmetric power issue, measure the signal strength in both directions. APs usually have enough power to transmit long distances, but sometimes battery-powered clients have a reply signal that has less power, and therefore the AP cannot detect their signal.

It is recommended that you match the transmission power of the AP to the least powerful wireless client—around 10 decibels per milliwatt (dBm) for iPhones and 14 dBm for most laptops.

Even if the signal is strong enough, other devices may also emit radiation and cause interference. To identify the difference, read the client Rx strength from the FortiGate GUI (under Monitor > WiFi Client Monitor) or CLI.

The Signal Strength/Noise value provides the received signal strength indicator (RSSI) of the wireless client. For example, a value of -85 dBm to -95 dBm is equal to about 10 dB levels; this is not a desirable signal strength. In the following screenshot, one of the clients is at 18 dB, which is getting close to the perimeter of its range.

note icon

The recommended Signal Strength/Noise value from and to the FortiAP by clients is in the range of -20 dBm to -65 dBm.

You can also confirm the transmission (Tx) power of the controller on the AP profile (wtp-profile) and the FortiAP (iwconfig), and check the power management (auto-Tx) options.

Controller configured transmitting power - CLI:

config wireless-controller wtp-profile

config <radio>

show

(the following output is limited to power levels)

auto-power-level : enable

auto-power-high : 17

auto-power-low : 10

Actual FortiAP transmitting power - CLI:

iwconfig wlan00

Result:

wlan00      IEEE 802.11ng   ESSID:"signal-check"

Mode:Master Frequency:2.412 GHz    Access Point:<MAC add>

Bit Rate:130 Mb/s   Tx-Power=28 dBm

 

Using FortiPlanner

The most thorough method to solve signal strength issues is to perform a site survey using FortiPlanner.

For details about FortiPlanner, visit the FortiPlanner website. You can download FortiPlanner here.

Sample depiction of a site survey using FortiPlanner

The site survey helps with the optimal placement for your APs based on the variables in your environment. You must provide the site survey detailed information such as a floor plan (to scale) and structural materials. FortiPlanner allows you to place the APs on the map and adjust the radio bands and power levels while providing you with visual wireless coverage.

The following list includes mechanisms for gathering further information on the client for Rx strength. The goal is to see how well the client is receiving the signal from the AP. You can also verify FortiAP signal strength on the client using WiFi client utilities, or third-party utilities such as InSSIDer or MetaGeek Chanalyzer.

  • Professional Site Survey software (Ekahau, AirMagnet survey Pro, FortiPlanner)
  • InSSIDer
  • On Windows: “netsh wlan show networks mode=bssid” (look for the BSSID, it's in % not in dBm)
  • On MacOS: Use the “airport” command:

“/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport” airport –s | grep <the_bssid> (live scan each time)

  • On Android: WiFiFoFum

Frequency interference

If the wireless signal seems to be strong but then periodically drops, this may be a symptom of frequency interference. Frequency interference is when another device also emits radio frequency using the same channel, co-channel, or adjacent channel, thereby overpowering or corrupting your signal. This is a common problem on a 2.4 GHz network.

There are two types of interference: coherent and non-coherent.

  • Coherent interference is a result of another device using the same channel as your AP, or poor planning of a wireless infrastructure. Perhaps the other nearby APs are using the same channel or the signal strength is too high.
  • Non-coherent interference is a result of other radio signals such as Bluetooth, microwave, cordless phone, or x-ray machines (as in medical environments).

The most common and simple solution for frequency interference is to change your operation channel. Typically, the channel can be set from 1 to 11 for the broadcast frequency, although it is recommended to use channels 1, 6, and 11 on the 2.4 GHz band.

Another solution, if it is appropriate for your location, is to use the 5 GHz band instead.

MetaGeek Chanalyzer

You can perform a site survey using spectrum analysis at various points in your environment to locate sources of interference. MetaGeek Chanalyzer is an example of a third-party utility used for spectrum analysis of complex WiFi networks.

Fortinet wireless adapters ignore signals of -95 dBm or less.

 

Throughput issues

Topics in this section help you identify throughput issues to suggest actions to address them.

Link testing

You can identify delays or lost packets by sending ping packets from your wireless client. If there is more than 10 ms of delay, there may be a problem with your wireless deployment, such as:

  • The client transmits a week signal. The host does not reach the AP.
  • The AP utilization is too high. Your AP is saturated with connected clients.
  • There is interference in the wireless network. Third-party signal can degrade your AP or the client's ability to detect signals between them.
  • The AP has a weak transmit power. The AP does not reach the host. This problem is not common in a properly deployed network, unless the client is too far away.

Performance testing

If the FortiAP gives poor throughput to the client, the link can drop. You can measure the link throughput or performance between two devices by using third-party application tools such as iPerf and jPerf.

Measuring the file transfer speed

Another way to get a sense of your throughput issues is to measure the speed of a file transfer on your network. Create a test file at a specific size and measure the speed at which Windows measures the transfer. The command below creates a 50 MB file. The file name is test.txt.

  • fsutil file createnew test.txt 52428800

The following image shows a network transfer speed of just over 24 Mbps. The theoretical speed of 802.11g is 54 Mbps, which is what this client is using. A wireless client is never likely to see the theoretical speed.

TKIP limitation

If you find that throughput is a problem, avoid WPA security encrypted with Temporal Key Integrity Protocol (TKIP) as it supports communications only at 54 Mbps. Use WPA-2 AES instead.

Speeds are very much based on what the client computer can handle as well. The maximum client connection rate of 130 Mbps is for 2.4 GHz on a 2x2, or 300 Mbps for 5 GHz on a 2x2 (using shortguard and channel bonding enabled).

If you want to get more than 54 Mbps with 802.11n, do not use legacy TKIP, use CCMP instead. This is standard for legacy compatibility.

IP packet fragmentation prevention in CAPWAP tunnels

TKIP is not the only possible source of decreased throughput. When a wireless client sends jumbo frames using a CAPWAP tunnel, it can result in data loss, jitter, and decreased throughput. For more details, see IP fragmentation of packets in CAPWAP tunnels.

Slow DTLS response

The following elements are involved in the CAPWAP association:

  • request
  • response
  • full of DTLS (Datagram Transport Layer Security) tunnel establishment
  • join
  • configuration

All of these element are bidirectional. If the DTLS response is slow, there could be a configuration error or an issue with a certificate during the discovery response. For details about the CAPWAP Protocol Specification, see RFC 5415 and RFC 5416.

Client connection issues

  1. If the client is unable to connect to FortiAP:
    • Make sure the client security and authentication settings match with FortiAP and also check the certificates.
    • Try upgrading the Wi-Fi adapter driver, FortiGate and FortiAP firmware.
    • If other clients can connect, the issue can be with device interoperability. Run debug commands and sniffer packets.
    • Look for rogue suppression by sniffing the wireless traffic and looking for the connection issue in the output (using the AP or wireless packet sniffer).
    • Try changing the IEEE protocol from 802.11n to 802.11bg or 802.11a only.
  2. If the client drops and reconnects:
    • The client might be de-authenticating periodically. Check the sleep mode on the client.
    • The issue could be related to power-saver settings. The client may need to update the drivers.
    • The issue could also be caused by flapping between APs. Check the roaming sensitivity settings on the client or the preferred wireless network settings on the client. If another WiFi network is available, the client may connect to it if it is a preferred network. Also, check the DHCP configuration as this configuration may be an IP conflict.
  3. If the client drops and never connects:
    • The client could have roamed to another SSID. Check the standby and sleep modes.
    • You may need to bring the interface up and down.
  4. If the client connects, but no IP address is acquired by the client:
    • Check the DHCP configuration and the network.
    • There could be a broadcast issue. Check the WEP encryption key and set a static IP address and VLANs.

Debugging client connection issues

To see the stage at which the client fails to connect, enable the client debug on the controller for problematic clients. Try to connect from the problematic client and run the following debug command, which allows you to see the four-way handshake of the client association:

diagnose wireless-controller wlac sta_filter <client MAC address> 2

Example of a successful client connection:

The following example debug output is for the above command. This example shows the successful association phase, DHCP phase, and the PSK key exchange (identified in color):

FG600B3909600253 #

91155.197 <ih> IEEE 802.11 mgmt::assoc_req <== 30:46:9a:f9:fa:34 vap signal-check rId 0 wId 0 00:09:0f:f3:20:45

91155.197 <ih> IEEE 802.11 mgmt::assoc_resp ==> 30:46:9a:f9:fa:34 vap signal-check rId 0 wId 0 00:09:0f:f3:20:45 resp 0

91155.197 <cc> STA_CFG_REQ(15) sta 30:46:9a:f9:fa:34 add ==> ws (0-192.168.35.1:5246) rId 0 wId 0

91155.197 <dc> STA add 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 bssid 00:09:0f:f3:20:45 NON-AUTH

91155.197 <cc> STA add 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45 sec WPA2 AUTO auth 0

91155.199 <cc> STA_CFG_RESP(15) 30:46:9a:f9:fa:34 <== ws (0-192.168.35.1:5246) rc 0 (Success)

91155.199 <eh> send 1/4 msg of 4-Way Handshake

91155.199 <eh>send IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=95 replay cnt 1

91155.199 <eh> IEEE 802.1X (EAPOL 99B) ==> 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45

91155.217 <eh> IEEE 802.1X (EAPOL 121B) <== 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45

91155.217 <eh> recv IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=117

91155.217 <eh> recv EAPOL-Key 2/4 Pairwise replay cnt 1

91155.218 <eh> send 3/4 msg of 4-Way Handshake

91155.218 <eh> send IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=175 replay cnt 2

91155.218 <eh> IEEE 802.1X (EAPOL 179B) ==> 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45

91155.223 <eh> IEEE 802.1X (EAPOL 99B) <== 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45

91155.223 <eh> recv IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=95

91155.223 <eh> recv EAPOL-Key 4/4 Pairwise replay cnt 2

91155.223 <dc> STA chg 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 bssid 00:09:0f:f3:20:45 AUTH

91155.224 <cc> STA chg 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45 sec WPA2 AUTO auth 1

91155.224 <cc> STA_CFG_REQ(16) sta 30:46:9a:f9:fa:34 add key (len=16) ==> ws (0-192.168.35.1:5246) rId 0 wId 0

91155.226 <cc> STA_CFG_RESP(16) 30:46:9a:f9:fa:34 <== ws (0-192.168.35.1:5246) rc 0 (Success)

91155.226 <eh> ***pairwise key handshake completed*** (RSN)

91155.257 <dc> DHCP Request server 0.0.0.0 <== host ADMINFO-FD4I2HK mac 30:46:9a:f9:fa:34 ip 172.16.1.16

91155.258 <dc> DHCP Ack server 172.16.1.1 ==> host mac 30:46:9a:f9:fa:34 ip 172.16.1.16 mask 255.255.255.0 gw 172.16.1.1

 

where:

  • Orange represents the association phase.
  • Blue represents the PSK exchange.
  • Green represents the DHCP phase.

It is important to note the messages for a correct association phase, four-way handshake, and DHCP phase.

Checking the WiFi password

An Administrator can view plain text passwords (captive-portal-radius-secret and passphrase) under config wireless-controller vap.

Note that security must be set as a WPA-personal setting.

FortiAP connection issues

A communication problem can arise from the FortiAP.

Some examples include:

  • The FortiAP is not connecting to the wireless controller.
  • One FortiAP intermittently disconnects and re-connects.
  • All FortiAPs intermittently disconnect and re-connect.

In the above cases:

  • Check networking on the distribution system for all related FortiAPs.
  • Check the authorization status of managed APs from the wireless controller.
  • Restart the cw_acd process.

    Note: A restart of the cw_acd process drops all APs.

  • For any wireless controller daemon crashes, check the controller crash log using the following command:
  • diagnose debug crashlog read

Debugging FortiAP connection issues

For a quick assessment of the association communication between the controller and the FortiAP, run the following sniffer command to see if you can verify that the AP is communicating to the controller by identifying the CAPWAP communication:

diagnose sniff packet <interface_name> “port 5246” 4

 

If you do not see this communication, then you can investigate the network or the settings on the AP to see why it is not reaching the controller.

To collect verbose output from the sniff that can be converted to a PCAP and viewed in Wireshark, use the following command:

diagnose sniff packet <interface_name> “port 5246” 6 0 l

 

The image below shows the beginning of the AP association to the controller. You can see the discovery Request and Response at the top.

Throughout debugging it is recommended to:

  • Enable SSH login to the FortiAP device so that you can log in and issue local debugging commands:

config wireless-controller wtp

edit "<FortiAP_serial_number>"

set override-allowaccess {disable|enable}

set allowaccess {https | ssh}

end

 

  • Try to connect to the wireless controller from the problematic FortiAP to verify routes exist.
  • Enable wtp (FortiAP) debugging on the wireless controller for problematic FortiAPs to determine the point at which the FortiAP fails to connect:

diag wireless-controller wlac wtp_filter FP112B3X13000193 0-192.168.6.8:5246 2

(replace the serial number and IP address of the FortiAP)

di de console timestamp en

di de application cw_acd 0x7ff

di de en

Example of a successful AP and controller association:

Here is another example of a successful association between the FortiAP and the wireless controller. This example includes elements of the CAPWAP protocol; Request, Response, DTLS, Join, and Configuration (identified in color). All of these elements are bi-directional. So, if the DTLS response is slow, there could be a configuration error.

56704.575 <msg> DISCOVERY_REQ (12) <== ws (0-192.168.35.1:5246)

56704.575 <msg> DISCOVERY_RESP (12) ==> ws (0-192.168.35.1:5246)

56707.575 <msg> DISCOVERY_REQ (13) <== ws (0-192.168.35.1:5246)

56707.575 <msg> DISCOVERY_RESP (13) ==> ws (0-192.168.35.1:5246)

56709.577 <aev> - CWAE_INIT_COMPLETE ws (0-192.168.35.1:5246)

56709.577 <aev> - CWAE_LISTENER_THREAD_READY ws (0-192.168.35.1:5246)

56709.577 <fsm> old CWAS_START(0) ev CWAE_INIT_COMPLETE(0) new CWAS_IDLE(1)

56709.577 <fsm> old CWAS_IDLE(1) ev CWAE_LISTENER_THREAD_READY(1) new CWAS_DTLS_SETUP(4)

56709.623 <aev> - CWAE_DTLS_PEER_ID_RECV ws (0-192.168.35.1:5246)

56709.623 <aev> - CWAE_DTLS_AUTH_PASS ws (0-192.168.35.1:5246)

56709.623 <aev> - CWAE_DTLS_ESTABLISHED ws (0-192.168.35.1:5246)

56709.623 <fsm> old CWAS_DTLS_SETUP(4) ev CWAE_DTLS_PEER_ID_RECV(7) new CWAS_DTLS_AUTHORIZE(2)

56709.623 <fsm> old CWAS_DTLS_AUTHORIZE(2) ev CWAE_DTLS_AUTH_PASS(3) new CWAS_DTLS_CONN(5)

56709.623 <fsm> old CWAS_DTLS_CONN(5) ev CWAE_DTLS_ESTABLISHED(8) new CWAS_JOIN(7)

56709.625 <msg> JOIN_REQ (14) <== ws (0-192.168.35.1:5246)

56709.625 <aev> - CWAE_JOIN_REQ_RECV ws (0-192.168.35.1:5246)

56709.626 <fsm> old CWAS_JOIN(7) ev CWAE_JOIN_REQ_RECV(12) new CWAS_JOIN(7)

56709.629 <msg> CFG_STATUS (15) <== ws (0-192.168.35.1:5246)

56709.629 <aev> - CWAE_CFG_STATUS_REQ ws (0-192.168.35.1:5246)

56709.629 <fsm> old CWAS_JOIN(7) ev CWAE_CFG_STATUS_REQ(13) new CWAS_CONFIG(8)

56710.178 <msg> CHG_STATE_EVENT_REQ (16) <== ws (0-192.168.35.1:5246)

56710.178 <aev> - CWAE_CHG_STATE_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.178 <fsm> old CWAS_CONFIG(8) ev CWAE_CHG_STATE_EVENT_REQ_RECV(23) new CWAS_DATA_CHAN_SETUP(10)

56710.220 <aev> - CWAE_DATA_CHAN_CONNECTED ws (0-192.168.35.1:5246)

56710.220 <msg> DATA_CHAN_KEEP_ALIVE <== ws (0-192.168.35.1:5246)

56710.220 <aev> - CWAE_DATA_CHAN_KEEP_ALIVE_RECV ws (0-192.168.35.1:5246)

56710.220 <msg> DATA_CHAN_KEEP_ALIVE ==> ws (0-192.168.35.1:5246)

56710.220 <fsm> old CWAS_DATA_CHAN_SETUP(10) ev CWAE_DATA_CHAN_CONNECTED(32) new CWAS_DATA_CHECK(11)

56710.220 <aev> - CWAE_DATA_CHAN_VERIFIED ws (0-192.168.35.1:5246)

56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_KEEP_ALIVE_RECV(35) new CWAS_DATA_CHECK(11)

56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_VERIFIED(36) new CWAS_RUN(12)

56710.228 <msg> WTP_EVENT_REQ (17) <== ws (0-192.168.35.1:5246)

56710.228 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.228 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56710.230 <msg> CFG_UPDATE_RESP (1) <== ws (0-192.168.35.1:5246) rc 0 (Success)

56710.230 <aev> - CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)

56710.230 <msg> WTP_EVENT_REQ (18) <== ws (0-192.168.35.1:5246)

56710.230 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.230 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)

56710.230 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56710.231 <msg> WTP_EVENT_REQ (19) <== ws (0-192.168.35.1:5246)

56710.231 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.231 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56710.232 <msg> CFG_UPDATE_RESP (2) <== ws (0-192.168.35.1:5246) rc 0 (Success)

56710.232 <aev> - CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)

56710.232 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)

56710.233 <msg> WTP_EVENT_REQ (20) <== ws (0-192.168.35.1:5246)

56710.233 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.233 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56712.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 3 dbg 00000000 pkts 12493 0

56715.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 6 dbg 00000000 pkts 12493 0

56718.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 9 dbg 00000000 pkts 12493 0

56719.253 <aev> - CWAE_AC_ECHO_INTV_TMR_EXPIRE ws (0-192.168.35.1:5246)

56719.253 <fsm> old CWAS_RUN(12) ev CWAE_AC_ECHO_INTV_TMR_EXPIRE(39) new CWAS_RUN(12)

56719.576 <msg> ECHO_REQ (21) <== ws (0-192.168.35.1:5246)

56719.576 <aev> - CWAE_ECHO_REQ_RECV ws (0-192.168.35.1:5246)

56719.577 <fsm> old CWAS_RUN(12) ev CWAE_ECHO_REQ_RECV(27) new CWAS_RUN(12)

 

where:

  • Orange represents the Discovery phase.
  • Blue indicates that the control channels have been established using DTLS.
  • Green represents the access point Discovery and Join phase.
  • Purple represents the Clear Text channel.
  • Pink indicates that the FortiAP is successfully connected to the wireless controller.

Best practices for OSI common sources of wireless issues

Not all WiFi problems are related to signal strength, interference, or misconfiguration. The following OSI model identifies some of the more common issues per layer.

Best practices for troubleshooting vary depending on the affected layer. See the following illustration.

Common sources of wireless issues

 

Best practices for Layer 1

Common physical layer issues include:

  • weak received signal
  • WiFi capability: 802.11b, 1x1, 2x2
  • co-channel WiFi interference
  • side band WiFi interference
  • non 802.11 noise (such as microwave ovens)

To avoid physical layer issues:

  • Determine the RST (Receiver Sensitivity Threshold) for your device, or use -70 dBm as a rule of thumb.
  • Match the AP TX output power to the client TX output power.
  • Use DFS (Dynamic Frequency Selection) for high performance data 20/40 MHz.
  • Use 5 GHz UNII-1 & 3 (Non-DFS) bands with static channel assignment for latency-sensitive applications.
  • Do not use 40 MHz channels in 2.4 GHz band. (FortiOS does not allow channel bonding.)

Best practices for Layer 2

Common data link (MAC) layer issues include:

  • too many clients on a single channel (CSMA/CA) backoff
  • too many high-priority traffic clients (WMM)
  • incorrect password or encryption settings
  • too many beacons (in high-density installations)

To avoid data link layer issues:

  • Only use CCMP/AES (WPA2) encryption (not TKIP).
  • In high-density deployments, turn off SSID broadcast or turn down SSID rates. Review and possibly reduce the beacon interval.
  • Determine the best cell size for applications:
    • For few users and low bandwidth latency sensitive applications, use high-transmit power to create larger cells.
    • For high-performance and high-capacity installations, use lower transmit power to create smaller cells (set FortiPlanner at 10 dBm TX power), but bear in mind that this setting requires more roaming.

Cells and co-channel interference

In high-density deployments, multiple APs are used, and each one services an area called a cell. However, these cells can cause interference with each other. This is a common problem. The radio signal from one AP interferes with, or cancels out, the radio signal from another AP.

In the following diagram, note the interference zone created by one radio, causing interference on its neighboring APs.

The interference zone can be twice the radius of the signal, and the signal at its edge can be -67 dBm.

Reducing co-channel interference

For best results, use a honeycomb pattern as a deployment strategy. The idea is to stagger repeated channels furthest from each other to avoid interference.

Best practices for Layer 3 and above

For TCP/IP layers and above, a common source of latency, or slowness in the wireless traffic, is too many broadcasts or multicasts. These types of issues can result from non-business or unwanted traffic, or both.

To resolve issues at the TCP/IP layer and above, you can:

  • identify business-critical applications
  • use Application Control, Web Filtering, Traffic Shaping, and QoS to prioritize applications
    • Identify unwanted traffic, high-bandwidth web-related traffic, and use Security Profiles.
    • Use the traffic shaping on a policy to rate-limit this traffic.
  • You perform these configurations directly on the FortiGate.

Packet sniffer

Capturing the traffic between the controller and the FortiAP can help you identify most FortiAP and client connection issues.

CAPWAP packet sniffer

The first recommended technique consists of sniffing the CAPWAP traffic.

  • Enable plain control on the controller and on the FortiAP to capture clear control traffic on UDP port 5246.
    • On the controller:

    diagnose wireless-controller wlac plain-ctl <FortiAP_serial_number> 1

    Result:

    WTP 0-FortiAP2223X11000107 Plain Control: enabled

    • On the FortiAP:

    cw_diag plain-ctl 1

    Result:

    Current Plain Control: enabled

Note that some issues are related to the keep-alive for control and data channel.

Data traffic on UDP port 5247 is not encrypted. The data itself is encrypted by the wireless security mechanism.

Data traffic is helpful to troubleshoot most of the issues related to station association, EAP authentication, WPA key exchange, roaming, and FortiAP configuration.

You can also set up a host or server to which you can forward the CAPWAP traffic:

  1. Configure the host or server to which CAPWAP traffic is forwarded:

    diagnose wireless-controller wlac sniff-cfg <Host_IP_address> 88888

    Result:

    Current Sniff Server: 192.168.25.41, 23352

  2. Choose which traffic to capture, the interface to which the FortiAP is connected, and the FortiAP serial number:

    diagnose wireless-controller wlac sniff <interface_name> <FortiAP_serial_number> 2

    Result:

    WTP 0-FortiAP2223X11000107 Sniff: intf port2 enabled (control and data message)

    In the above syntax, the '2' captures the control and data message. The '1' would capture only the control message and '0' would disable it.

  3. Run Wireshark on the host or server to capture CAPWAP traffic from the controller.
  4. Decode the traffic as IP to check inner CAPWAP traffic.
Example CAPWAP packet capture

The following image shows an example of a CAPWAP packet capture, where you can see the following details:

  • Layer 2 header
  • sniffed traffic encapsulated into Internet Protocol for transport
  • CAPWAP encapsulated into UDP for sniffer purpose and encapsulated into IP
  • CAPWAP control traffic on UDP port 5246
  • CAPWAP payload

Wireless traffic packet sniffer

The second recommended technique consists of sniffing the wireless traffic directly on the air using your FortiAP.

Wireless traffic packet capture

Packet captures are useful for troubleshooting all wireless client related issues because you can verify data rate and 802.11 parameters, such as radio capabilities, and determine issues with wireless signal strength, interference, or congestion on the network.

A radio can only capture one frequency at a time; one of the radios is set to sniffer mode depending on the traffic or channel required. You must use two FortiAPs to capture both frequencies at the same time.

  • Set a radio on the FortiAP to monitor mode.

    iwconfig wlan10

     

    Result:

    wlan10    IEEE 802.11na     ESSID:""

    Mode:Monitor  Frequency:5.18 GHz  Access Point: Not-Associated

 

  • The capture file is stored under the temp directory as wl_sniff.pcap

    /tmp/wl_sniff.cap

  • Remember that the capture file is only stored temporarily. If you want to save it, upload it to a TFTP server before rebooting or changing the radio settings.
  • The command cp wl_sniff.cap newname.pcap allows you to rename the file.
  • Rather than TFTP the file, you can also log in to the AP and retrieve the file via the web interface. Move the file using the command: mv name /usr/www.

    You can verify that the file was moved using the command cd/usr/www and then browsing to: <fortiAP_IP>/filename.

Syntax

The following syntax demonstrates how to set the radio to sniffer mode (configurable from the CLI only). Sniffer mode provides options to filter for specific traffic to capture. Notice that you can determine the buffer size, which channel to sniff, the AP MAC address, and select if you want to sniff the beacons, probes, controls, and data channels.

configure wireless-controller wtp-profile

edit <profile_name>

configure <radio>

set mode sniffer

set ap-sniffer-bufsize 32

set ap-sniffer-chan 1

set ap-sniffer-addr 00:00:00:00:00:00

set ap-sniffer-mgmt-beacon enable

set ap-sniffer-mgmt-probe enable

set ap-sniffer-mgmt-other enable

set ap-sniffer-ctl enable

set ap-sniffer-data enable

end

end

 

Once you have performed the previous CLI configuration, you can see the packet sniffer mode selected in the GUI dashboard under WiFi & Switch Controller > FortiAP Profiles and WiFi & Switch Controller > Managed FortiAPs. Bear in mind that if you change the mode from the GUI, you need to return to the CLI to re-enable the sniffer mode.

To disable the sniffer profile in the CLI, use the following commands:

config wireless-controller wtp-profile

edit <profile_name>

config <radio>

set ap-sniffer-mgmt-beacon disable

set ap-sniffer-mgmt-probe disable

set ap-sniffer-mgmt-other disable

set ap-sniffer-ctl disable

set ap-sniffer-data disable

end

end

 

 

If you change the radio mode before sending the file wl_sniff.cap to an external TFTP, the file is deleted and you lose your packet capture.

Example AP packet capture

The following image shows an example of the AP packet capture with the following details:

  • capture header showing channel 36
  • beacon frame
  • source, destination, and BSSID of the beacon frame
  • SSID of the beacon frame

Debug commands

For a list of debug options available for the wireless controller, use the following command on the controller:

diagnose wireless-controller wlac help

Sample outputs

Syntax

diagnose wireless-controller wlac -c vap

(This command lists the information about the virtual access point, including its MAC address, the BSSID, its SSID, the interface name, and the IP address of the APs that are broadcasting it.)

 

Result:

bssid              ssid      intf        vfid:ip-port rId wId

00:09:0f:d6:cb:12 Office Office    ws (0-192.168.3.33:5246) 0 0

00:09:0f:e6:6b:12 Office Office    ws (0-192.168.1.61:5246) 0 0

06:0e:8e:27:dc:48 Office Office   ws (0-192.168.3.36:5246) 0 0

0a:09:0f:d6:cb:12 public publicAP ws (0-192.168.3.33:5246) 0 1

 

Syntax

diagnose wireless-controller wlac -c darrp

(This command lists the information pertaining to the radio resource provisioning statistics, including the AP serial number, the number of channels set to choose from, and the operation channel. Note that the 5 GHz band is not available on these APs listed.)

 

Result:

wtp_id           rId  base_mac          index       nr_chan vfid 5G oper_chan age

FAP22A3U10600400 0    00:09:0f:d6:cb:12 0                3       0               No 1                                          87588

FW80CM3910601176 0    06:0e:8e:27:dc:48 1     3       0    No 6         822

 

Extension information support

You can enable or disable extension information at wtp-profile, and use the diagnose option below to print out the detail of extension information.

Syntax

config wireless-controller wtp-profile

edit test

set lldp [enable | disable]

set ext-info-enable

[enable | disable] --> Enable or disable station, VAP, and radio extension information.

end

end

 

diagnose wireless-controller wlac -d [wtp | vap | sta]

 

where:

  • wlac -d wtp [SN|name] [reset] --> List or reset wtp info (data).
  • wlac -d vap [bssid] [reset] --> List or reset vap info (data). .
  • wlac -d sta [mac] [reset] --> list or reset sta info (data).