Reference

This chapter provides some reference information pertaining to wireless networks.

FortiAP web-based manager

Wireless radio channels

WiFi event types

FortiAP CLI

FortiAP web-based manager

FortiAP web-based manager

You can access the FortiAP unit’s built-in web-based manager. This is useful to adjust settings that are not available through the FortiGate unit’s WiFi Controller. Logging into the FortiAP web-based manager is similar to logging into the FortiGate web-based manager.

System Information

Status

The Status section provides information about the FortiAP unit.

You can:

• Select Change to change the Host Name. l Select Update in Firmware Version to upload a new FortiAP firmware file from your computer.
• Select Change Password to change the administrator password. l Select Backup to save the current FortiAP configuration as a file on your computer. l Select Restore to load a configuration into your FortiAP unit from a file on your computer.

Network Configuration

Select DHCP or select Static and specify the IP address, netmask, and gateway IP address. Administrative Access settings affect access after the FortiAP has been authorized. By default, HTTP access needed to access the FortiAP web-based manager is enabled, but Telnet access is not enabled.

Connectivity

These settings determine how the FortiAP unit connects to the FortiGate WiFi controller.

FortiAP web-based manager

Uplink	Ethernet – wired connection to the FortiGate unit (default) Mesh – WiFi mesh connection Ethernet with mesh backup support
Mesh AP SSID	Enter the SSID of the mesh root. Default: fortinet.mesh.root
Mesh AP Password	Enter password for the mesh SSID.
Ethernet Bridge	Bridge the mesh SSID to the FortiAP Ethernet port. This is available only whe Uplink is Mesh.

WTP Configuration

AC Discovery Type settings affect how the FortiAP unit discovers a FortiGate WiFi controller. By default, this is set to Auto which causes the FortiAP unit to cycle through all of the discovery methods until successful. For more information see Controller discovery methods.

AC Discovery Type	Static, DHCP, DNS, Broadcast, Multicast, Auto
AC Control Port	Default port is 5246.
AC IP Address 1 AC IP Address 2 AC IP Address 3	You enter up to three WiFi controller IP addresses for static discovery. Routing must be properly configured in both directions.
AC Host Name 1 AC Host Name 2 AC Host Name 3	As an alternetive to AC IP addresses, you can enter their fully qualified domain names (FQDNs).
AC Discovery Multicast Address	224.0.1.140
AC Discovery DHCP Option Code	When using DHCP discovery, you can configure the DHCP server to provide the controller address. By default the FortiAP unit expects this in option 138.

AC Data Channel Security by default accepts either DTLS-encrypted or clear text data communication with the WiFi controller. You can change this setting to require encryption or to use clear text only.

Wireless Information

The Wireless Information page provides current information about the operation of the radios and the type Uplink in use.

Wireless radio channels

Wireless radio channels

IEEE 802.11a/n channels

The following table lists the channels supported on FortiWiFi products that support the IEEE 802.11a and 802.11n wireless standards. 802.11a is available on FortiWiFi models 60B and higher. 802.11n is available on FortiWiFi models 80CM and higher.

All channels are restricted to indoor usage except in the Americas, where both indoor and outdoor use is permitted on channels 52 through 64 in the United States.

IEEE 802.11a/n (5-GHz Band) channel numbers

Channel number	Frequency (MHz)	Regulatory Areas Americas Europe	Taiwan	Singapore Japan
34	5170			•
36	5180	•               •		•
38	5190
40	5200	•               •		•                •
42	5210
44	5220	•               •		•                •
46	5230
48	5240	•               •		•                •
149	5745	•	•	•
153	5765	•	•	•
157	5785	•	•	•
161	5805	•	•	•
165	5825	•		•

IEEE 802.11b/g/n channel numbers

The following table lists IEEE 802.11b/g/n channels. All FortiWiFi units support 802.11b and 802.11g. Newer models also support 802.11n.

Wireless radio channels

Mexico is included in the Americas regulatory domain. Channels 1 through 8 are for indoor use only. Channels 9 through 11 can be used indoors and outdoors. You must make sure that the channel number complies with the regulatory standards of Mexico.

IEEE 802.11b/g/n (2.4-GHz Band) channel numbers

Channel number	Frequency (MHz)	Regulatory Areas Americas EMEA	Israel	Japan
1	2412	•                   •	indoor	•
2	2417	•                   •	indoor	•
3	2422	•                   •	indoor	•
4	2427	•                   •	indoor	•
5	2432	•                   •	•	•
6	2437	•                   •	•	•
7	2442	•                   •	•	•
8	2447	•                   •	•	•
9	2452	•                   •	•	•
10	2457	•                   •	•	•
11	2462	•                   •	•	•
12	2467	•	•	•
13	2472	•	•	•
14	2484			b only

View all Country & Regcodes/Regulatory Domains

The following CLI command can be entered to view a list of the Country & Regcodes/Regulatory Domains supported by Fortinet:

cw_diag -c all-countries

Below is a table showing a sample of the list displayed by entering this command:

Country-code Region-code Domain	ISO-name Name
0                      A                    FCC3 & FCCA	NA             NO_COUNTRY_SET

WiFi event types

Country-code Region-code Domain	ISO-name Name
8                        W                   NULL1 & WORLD	AL              ALBANIA
12                      W                   NULL1 & WORLD	DZ              ALGERIA
16                      A                    FCC3 & FCCA	AS              AMERICAN SAMOA
…                    …                               …	…                             …

WiFi event types

Event type	Description
rogue-ap-detected	A rogue AP has been detected (generic).
rogue-ap-off-air	A rogue AP is no longer detected on the RF side.
rogue-ap-on-wire	A rogue AP has been detected on wire side (connected to AP or controller L2 network).
rogue-ap-off-wire	A rogue AP is no longer detected on wire.
rogue-ap-on-air	A rogue AP has been detected on the RF side.
fake-ap-detected	A rogue AP broadcasting on the same SSIDs that you have in your managed APs has been detected.
fake-ap-on-air	The above fake AP was detected on the RF side.

FortiAP CLI

The FortiAP CLI controls radio and network operation through the use of variables manipulated with the cfg command. There are also diagnostic commands.

The cfg command include the following

cfg -s		List variables.
cfg -a var=value		Add or change a variable value.
cfg -c		Commit the change to flash.
cfg -x		Reset settings to factory defaults.

 

cfg -r var	Remove variable.
cfg -e	Export variables.
cfg -h	Display help for all commands.

The configuration variables are:

Var	Description and Values
AC_CTL_PORT	WiFi Controller control (CAPWAP) port. Default 5246.
AC_DATA_CHAN_SEC	Data channel security. 0 – Clear text 1 – DTLS (encrypted) 2 – Accept either DTLS or clear text (default)
AC_DISCOVERY_TYPE	1 – Static. Specify WiFi Controllers 2 – DHCP 3 – DNS 5 – Broadcast 6 – Multicast 0 – Cycle through all of the discovery types until successful.
AP_IPADDR AP_NETMASK IPGW	These variables set the FortiAP unit IP address, netmask and default gateway when ADDR_MODE is STATIC. Default 192.168.1.2 255.255.255.0, gateway 192.168.1.1.
AC_HOSTNAME_1 AC_HOSTNAME_2 AC_HOSTNAME_3	WiFi Controller host names for static discovery.
AC_IPADDR_1 AC_IPADDR_2 AC_IPADDR_3	WiFi Controller IP addresses for static discovery.
AC_DISCOVERY_DHCP_OPTION_CODE	Option code for DHCP server. Default 138.
AC_DISCOVERY_MC_ADDR	Multicast address for controller discovery. Default 224.0.1.140.

 

Var	Description and Values
ADDR_MODE	How the FortiAP unit obtains its IP address and netmask. DHCP – FortiGate interface assigns address. STATIC – Specify in AP_IPADDR and AP_NETMASK. Default is DHCP.
ADMIN_TIMEOUT	Administrative timeout in minutes. Applies to Telnet and web-based manager sessions. Default is 5 minutes.
AP_MGMT_VLAN_ID	Non-zero value applies VLAN ID for unit management. Default: 0.
AP_MODE	FortiAP operating mode. 0 – Thin AP (default) 2 – Unmanaged Site Survey mode. See SURVEY variables.
BAUD_RATE	Console data rate: 9600, 19200, 38400, 57600, or 115200 baud.
DNS_SERVER	DNS Server for clients. If ADDR_MODE is DHCP the DNS server is automatically assigned.
FIRMWARE_UPGRADE	Default is 0.
HTTP_ALLOW	Access to FortiAP web-based manager 1 – Yes (default), 0 – No.
LED_STATE	Enable/disable status LEDs. 0 – LEDs enabled, 1 – LEDs disabled, 2 – follow AC setting.
LOGIN_PASSWD	Administrator login password. By default this is empty.
STP_MODE	Spanning Tree Protocol. 0 is off. 1 is on.
TELNET_ALLOW	By default (value 0), Telnet access is closed when the FortiAP unit is authorized. Set value to 1 to keep Telnet always available.
WTP_LOCATION	Optional string describing AP location.
Mesh variables

 

Var	Description and Values
MESH_AP_BGSCAN	Enable or disable background mesh root AP scan. 0 – Disabled 1 – Enabled
MESH_AP_BGSCAN_RSSI	If the root AP’s signal is weak, and lower than the received signal strength indicator (RSSI) threshold, the WiFi driver will immediately start a new round scan and ignore the configured MESH_AP_BGSCAN_PERIOD delays. Set the value between 0-127. After the new round scan is finished, a scan done event is passed to wtp daemon to trigger roaming.
MESH_AP_BGSCAN_PERIOD	Time in seconds that a delay period occurs between scans. Set the value between 1-3600.
MESH_AP_BGSCAN_IDLE	Time in milliseconds. Set the value between 0-1000.
MESH_AP_BGSCAN_INTV	Time in milliseconds between channel scans. Set the value between 200-16000.
MESH_AP_BGSCAN_DUR	Time in milliseconds that the radio will continue scanning the channel. Set the value between 10-200.
MESH_AP_SCANCHANLIST	Specify those channels to be scanned.
MESH_AP_TYPE	Type of communication for backhaul to controller: 0 – Ethernet (default) 1 – WiFi mesh 2 – Ethernet with mesh backup support
MESH_AP_SSID	SSID for mesh backhaul. Default: fortinet.mesh.root
MESH_AP_BSSID	WiFi MAC address
MESH_AP_PASSWD	Pre-shared key for mesh backhaul.
MESH_ETH_BRIDGE	1 – Bridge mesh WiFi SSID to FortiAP Ethernet port. This can be used for point-to-point bridge configuration. This is available only when MESH_AP_TYPE =1. 0 – No WiFi-Ethernet bridge (default).
Var                                                                 Description and Values
MESH_MAX_HOPS                      Maximum number of times packets can be passed from node to node on the mesh. Default is 4.
The following factors are summed and the FortiAP associates with the lowest scoring mesh AP.
MESH_SCORE_HOP_WEIGHT                Multiplier for number of mesh hops from root. Default 50.
MESH_SCORE_CHAN_WEIGHT              AP total RSSI multiplier. Default 1.
MESH_SCORE_RATE_WEIGHT              Beacon data rate multiplier. Default 1.
Band weight (0 for 2.4GHz, 1 for 5GHz) multiplier. Default MESH_SCORE_BAND_WEIGHT 100.
MESH_SCORE_RSSI_WEIGHT              AP channel RSSI multiplier. Default 100.
Survey variables
SURVEY_SSID                        SSID to broadcast in site survey mode (AP_MODE=2).
SURVEY_TX_POWER                     Transmitter power in site survey mode (AP_MODE=2).
SURVEY_CH_24                        Site survey transmit channel for the 2.4Ghz band (default 6).
Site survey transmit channel for the 5Ghz band (default SURVEY_CH_50 36).
SURVEY_BEACON_INTV                  Site survey beacon interval. Default 100msec.

cw_diag	help		Display help for all diagnose commands.
cw_diag	uptime		Show daemon uptime.
cw_diag	–tlog	<on|off>	Turn on/off telnet log message.
cw_diag	–clog	<on|off>	Turn on/off console log message.
cw_diag 38400 |	baudrate [9600 | 19200 | 57600 | 115200]		Set the console baud rate.

Previously, FortiAP accepted Telnet and HTTP connection to any virtual interfaces that have an IP address. For security reasons, Telnet and HTTP access are now limited to br0 or br.vlan for AP_MGMT_VLAN_ID.

Diagnose commands include:

 

cw_diag	plain-ctl [0|1]		Show or change current plain control setting.
cw_diag	sniff-cfg ip port		Set sniff server ip and port.
cw_diag	sniff [0|1|2]		Enable/disable sniff packet.
cw_diag	stats wl_intf		Show wl_intf status.
cw_diag	admin-timeout [30]		Set shell idle timeout in minutes.
cw_diag	-c	wtp-cfg	Show current wtp config parameters in control plane.
cw_diag	-c	radio-cfg	Show current radio config parameters in control plane.
cw_diag	-c	vap-cfg	Show current vaps in control plane.
cw_diag	-c	ap-rogue	Show rogue APs pushed by AC for on-wire scan.
cw_diag	-c	sta-rogue	Show rogue STAs pushed by AC for on-wire scan.
cw_diag	-c	arp-req	Show scanned arp requests.
cw_diag	-c	ap-scan	Show scanned APs.
cw_diag	-c	sta-scan	Show scanned STAs.
cw_diag	-c	sta-cap	Show scanned STA capabilities.
cw_diag	-c	wids	Show scanned WIDS detections.
cw_diag	-c	darrp	Show darrp radio channel.
cw_diag	-c	mesh	Show mesh status.
cw_diag	-c	mesh-veth-acinfo	Show mesh veth ac info, and mesh ether type.
cw_diag	-c	mesh-veth-vap	Show mesh veth vap.
cw_diag	-c	mesh-veth-host	Show mesh veth host.
cw_diag	-c	mesh-ap	Show mesh ap candidates.
cw_diag	-c	scan-clr-all	Flush all scanned AP/STA/ARPs.
cw_diag	-c	ap-suppress	Show suppressed APs.
cw_diag	-c	sta-deauth	De-authenticate an STA.

Link aggregation can also be set in the CLI. Link aggregation is used to combine multiple network connections in parallel in order to increase throughput beyond what a single connection could sustain.

• FortiAP 320B and 320C models are supported. l FortiAP 112B and 112D models cannot support link aggregation.
• NPI FAP-S3xxCR and “wave2” FAP/FAP-S models will have link aggregation feature via synchronization with regular FortiAP trunk build.

Useful debugging commands

For a comprehensive list of useful debug options you can use the following help commands on the controller:

diagnose wireless-controller wlac help

(this command lists the options available that pertain to the wireless controller)

diagnose wireless-controller wlwtp help

(this command lists the options available that pertain to the AP)

Useful debugging commands

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 5GHz 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

 

Packet sniffer

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

This section describes the following recommended packet sniffing techniques:

l CAPWAP packet sniffer l Wireless traffic packet sniffer

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 l 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/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’s serial number: diagnose wireless-controller wlac sniff <interface_name> <FortiAP_serial_number> 2

Result:

Packet sniffer

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

In the above syntax, the ‘2’ captures the control and data message—’1′ would capture only the control message, and ‘0’ would disable it.

3. Run Wireshark on the host/server to capture CAPWAP traffic from the controller. l 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 Layer 2 header; the 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; and 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. l Set a radio on the FortiAP to monitor mode.

Packet sniffer

iwconfig wlan10

Result:

wlan10 IEEE 802.11na    ESSID:””

Mode:Monitor Frequency:5.18 GHz Access Point: Not-Associated l 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. l 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 retrive the file via the web interface. Move the file

using the command: mv name /usr/www

You can verify 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’s 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’ve performed the previous CLI configuration, you’ll be able to 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’ll have 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

Useful debugging commands

end

Example AP packet capture

The following image shows an example of the AP packet capture. Note the capture header showing channel 36; the beacon frame; the source, destination, and BSSID of the beacon frame; and the SSID of the beacon frame.

General problems

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 below).

Common sources of wireless issues

Best practices for Layer 1

Common physical layer issues include:

• Weak received signal, l WiFi capability: 802.11b, 1×1, 2×2, l Co-channel WiFi interference, General problems
• Side band WiFi interference, l Non 802.11 noise (microwave ovens…).

To avoid physical layer issues:

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

Best practices for Layer 2

Common data link (MAC) layer issues include:

• Too many clients on a single channel (CSMA/CA) backoff, l Too many high-priority traffic clients (WMM), l Incorrect password or encryption settings, l Too many beacons (in dense installs).

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. l 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/high capacity installations, use lower transmit power to create smaller cells (set FortiPlanner at 10dBm TX power), but bear in mind that this will require 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 neighbouring APs.

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

General problems

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 and/or unwanted traffic.

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

Packet sniffer

• 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. l Use the traffic shaper on a policy to rate-limit this traffic.

These configurations are performed directly on the FortiGate.

Connection issues

If the client has a connectivity issue that is not due to signal strength, the solution varies by the symptom.

Client connection issues

1. If client is unable to connect to FortiAP:
   • Make sure the client’s security and authentication settings match with FortiAP and check the certificates as well. l Try upgrading the Wi-Fi adapter driver and FortiGate/FortiAP firmware. l If other clients can connect, it could be interoperability; run debug commands and sniffer packets.
   • Look for rogue suppression by sniffing the wireless traffic and looking for the disconnect in the output (using the AP or wireless packet sniffer). l Try changing the IEEE protocol from 802.11n to 802.11bg or 802.11a only.
2. If the client drops and reconnects:

Connection

• The client might be de-authenticating periodically. Check the sleep mode on the client. l The issue could be related to power-saver settings. The client may need to udpate 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 it may be an IP conflict.

3. If the client drops and never connects:
   • It could have roamed to another SSID, so check the standby and sleep modes. l 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. l It could be a broadcast issue, so check the WEP encryption key and set a static IP address and VLANs.

Debug

You should also enable client debug on the controller for problematic clients to see the stage at which the client fails to connect. 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 is a sample debug output for the above command, with successful association/DHCP phases and 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 (0192.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:

l orange represents the association phase, l blue represents the PSK exchange, l and green represents the DHCP phase.

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

FortiAP connection issues

Clients are not the only device that can fail to connect, of course. A communication problem could arise from the FortiAP.

Some examples include:

• The FortiAP is not connecting to the wireless controller. l One FortiAP intermittently disconnects and re-connects. l All FortiAPs intermittently disconnect and re-connect. l Unable to Telnet to FortiAP from controller/administrator workstation.

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: All APs will drop if you do this, and you may be troubleshooting just one AP).
• Check the controller crash log for any wireless controller daemon crash using the following command:

diagnose debug crashlog read

Debug

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.

The following command allows you to collect verbose output from the sniff that can be converted to a PCAP and viewed in Wireshark.

Connection

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

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

Throughout debugging it is recommended to:

• Enable Telnet 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 {telnet | http | https | ssh}

end l 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:

The previous debug command provides similar output to the sample debug message below for a successful association between the FortiAP and the wireless controller. This includes the elements of the CAPWAP protocol; the Request, Response, DTLS, Join, and Configuration (identified in color). All of these are bi-directional, so if the DTLS response is slow, it may be an example of 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)

 

General problems

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:

l orange represents the Discovery phase, l blue indicates that the control channels have been established using DTLS, l green represents the access point Discovery and Join phase, l purple represents the Clear Text channel, l and pink indicates that the FortiAP successfully connected to the wireless controller.

Throughput issues

Sometimes communication issues can be caused by low performance.

Testing the link

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

l a weak transmit signal from the client (the host does not reach the AP) l the AP utilization is too high (your AP could be saturated with connected clients) l interference (third party signal could degrade your AP or client’s ability to detect signals between them) l weak transmit power from the AP (the AP does not reach the host) — not common in a properly deployed network, unless the client is too far away

Throughput

Keep in mind that water will also cause a reduction in radio signal strength for those making use out of outdoor APs or wireless on a boat.

Performance testing

If the FortiAP gives bad throughput to the client, the link may drop. The throughput or performance can be measured on your smartphone with third party applications tool such as iPerf and jPerf.

Measuring 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 will create a 50MB file.

l fsutil file createnew test.txt 52428800

The following image shows a network transfer speed of just over 24Mbps. The theoretical speed of 802.11g is 54Mbps, 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 54Mbps. 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 130Mbps is for 2.4GHz on a 2×2, or 300Mbps for 5Ghz on a 2×2 (using shortguard and channel bonding enabled).

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

Preventing IP fragmentation in CAPWAP

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.

Using the following commands you can customize the uplink rates and downlink rates in the CAPWAP tunnel to prevent fragmentation and avoid data loss.

config wireless-controller wtp edit new-wtp

(in 5.4, you must enable override-ip-fragment: set override-ip-fragment enable) set ip-fragment-preventing [tcp-mss-adjust | icmp-unreachable]

set tun-mtu-uplink [0 | 576 | 1500] set tun-mtu-downlink [0 | 576 | 1500]

end

end

The default value is 0, however the recommended value will depend on the type of traffic. For example, IPsec in tunnel mode has 52 bytes of overhead, so you might use 1400 or less for uplink and downlink.

Slowness in the DTLS response

It’s important to know all the elements involved in the CAPWAP association:

l Request l Response l DTLS l Join l Configuration

All of these are bidirectional. So if the DTLS response is slow, this might be the result of a configuration error. This issue can also be caused by a certificate during discovery response. You can read more about this in RFC 5416.

Signal strength issues

Poor signal strength is possibly the most common customer complaint. Below you will learn where to begin identifying and troubleshooting poor signal strength, and learn what information you can obtain from the customer to help resolve signal strength issues.

Asymmetric power issue

Asymmetric power issues are a typical problem. Wireless is two-way communication; high power access points (APs) can usually transmit a long distance, however, the client’s ability to transmit is usually not equal to that of the AP and, as such, cannot return transmission if the distance is too far.

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 14dBm for most laptops.

Even if the signal is strong enough, other devices may be emitting radiation as well, causing 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 -85dBm to -95dBm is equal to about 10dB levels; this is not a desirable signal strength.

In the following screenshot, one of the clients is at 18dB, which is getting close to the perimeter of its range.

Signal strength issues

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 PRO with a site survey

The most thorough method to solve signal strength issues is to perform a site survey. To this end, Fortinet offers the FortiPlanner, downloadable at http://www.fortinet.com/resource_center/product_downloads.html.

Signal strength

Sample depiction of a site survey using FortiPlanner

The site survey provides you with optimal placement for your APs based on the variables in your environment. You must provide the site survey detailed information including a floor plan (to scale), structural materials, and more. It will allow you to place the APs on the map and adjust the radio bands and power levels while providing you with visual wireless coverage.

Below is a list of 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. You can get similar tools from the app stores on Android and iOS devices.

• Professional Site Survey software (Ekahau, Airmagnet survey Pro, FortiPlanner) l InSSIDer l On Windows: “netsh wlan show networks mode=bssid” (look for the BSSID, it’s in % not in dBm!) l 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 Droid: 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 corrputing your signal. This is a common problem on a 2.4GHz network.

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

 

Throughput

• Coherent interference: 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: a result of other radio signals such as bluetooth, microwave, cordless phone, or (as in medical environments) x-ray machines.

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 you should always use channels 1, 6, and 11 on the 2.4GHz band.

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

MetaGeek Chanalyzer

You can perform a site survey using spectrum analysis at various points in your environment looking for signal versus interference/noise. MetaGeek Chanalyzer is an example of a third party utility which shows a noise threshold.

Note that a signal of -95dBm or less will be ignored by Fortinet wireless adapters.