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.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

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.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

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.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

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.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiAP shell command through CAPWAP control tunnel

Very often, the FortiAP in the field is behind a NAT device, and access to the FortiAP through Telnet or SSH is not available. As a troubleshooting enhancement, this feature allows an AP shell command up to 127-bytes sent to

the FAP, and FAP will run this command, and return the results to the controller using the CAPWAP tunnel.

The maximum output from a command is limited to 4M, and the default output size is set to 32K.

The FortiAP will only report running results to the controller after the command is finished. If a new command is sent to the AP before the previous command is finished, the previous command will be canceled.

Enter the following:

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 AP will not report results until the command is finished on the AP l run: controller sends the ap-cmd to the FAP to run l show: show current results reported by the AP in text l showhex: show current results reported by the AP in hex l clr: clear reported results

 

Signal strength

• r&s: run/show l r&sh: run/showhex

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Support for location-based services

FortiOS supports location-based services by collecting information about WiFi devices near FortiGate-managed access points, even if the devices don’t associate with the network.

Overview

Configuring location tracking

Viewing device location data on the FortiGate unit

Overview

WiFi devices broadcast packets as they search for available networks. The FortiGate WiFi controller can collect information about the interval, duration, and signal strength of these packets. The Euclid Analytics service uses this information to track the movements of the device owner. A typical application of this technology is to analyze shopper behavior in a shopping center. Which stores do people walk past? Which window displays do they stop to look at? Which stores do they enter and how long do they spend there? The shoppers are not personally identified, each is known only by the MAC address of their WiFi device.

After enabling location tracking on the FortiGate unit, you can confirm that the feature is working by using a specialized diagnostic command to view the raw tracking data. The Euclid Analytics service obtains the same data in its proprietary format using a JSON inquiry through the FortiGate unit’s web-based manager interface.

Configuring location tracking

You can enable location tracking in any FortiAP profile, using the CLI. Location tracking is part of location-based services. Set the station-locate field to enable. For example:

config wireless-controller wtp-profile edit “FAP220B-locate” set ap-country US config platform set type 220B

end config lbs set station-locate enable

end

end

Automatic deletion of outdated presence data

The FortiGate generates a log entry only the first time that station-locate detects a mobile client. No log is generated for clients that have been detected before. To log repeat client visits, previous station presence data must be deleted (flushed). The sta-locate-timer can flush this data periodically. The default period is 1800 seconds (30 minutes). The timer can be set to any value between 1 and 86400 seconds (24 hours). A setting of 0 disables the flush, meaning a client is logged only on the very first visit.

The timer is one of the wireless controller timers and it can be set in the CLI. For example:

Viewing device location data on the FortiGate unit                                                  Support for location-based services

config wireless-controller timers set sta-locate-timer 1800

end

The sta-locate-timer should not be set to less than the sta-capability-timer (default 30 seconds) because that could cause duplicate logs to be generated.

FortiPresence push REST API

When the FortiGate is located on a private IP network, the FortiPresence server cannot poll the FortiGate for information. Instead, the FortiGate must be configured to push the information to the FortiPresence server.

Enter the following command:

config wireless-controller wtp-profile edit “FP223B-GuestWiFi” config lbs set fortipresence {enable | disable} set fortipresence-server <ip-address> Default is 3000. set fortipresence-port <port> set fortipresence-secret <password> set fortipresence-project <name> set fortipresence-frequency <5-65535> Default is 30. set fortipresence-rogue {enable | disable} Enable/disable reporting of Rogue APs. set fortipresence-unassoc {enable | disable} Enable/disable reporting of unassociated devices.

end

end

Viewing device location data on the FortiGate unit

You can use the FortiGate CLI to list located devices. This is mainly useful to confirm that the location data feature is working, You can also reset device location data.

To list located devices diag wireless-controller wlac -c sta-locate

To reset device location data diag wireless-controller wlac -c sta-locate-reset

Example output

The following output shows data for three WiFi devices.

FWF60C3G11004319 # diagnose wireless-controller wlac -c sta-locate sta_mac vfid rid base_mac freq_lst frm_cnt frm_fst frm_last intv_sum intv2_sum intv3_ sum intv_min intv_max signal_sum signal2_sum signal3_sum sig_min sig_max sig_fst sig_last ap

00:0b:6b:22:82:61 0

FAP22B3U11005354 0 0 00:09:0f:f1:bb:e4 5745 257 708 56 651 1836 6441 0 12 -21832

1855438 -157758796 -88 -81 -84 -88 0

Support for location-based services                                                  Viewing device location data on the FortiGate unit

00:db:df:24:1a:67 0

FAP22B3U11005354 0 0 00:09:0f:f1:bb:e4 5745 42 1666 41 1625 97210 5831613 0 60 -3608 310072 -26658680 -90 -83 -85 -89 0

10:68:3f:50:22:29 0

FAP22B3U11005354 0 0 00:09:0f:f1:bb:e4 5745 102 1623 58 1565 94136 5664566 0 60 -8025 631703 -49751433 -84 -75 -78 -79 0

The output for each device appears on two lines. The first line contains only the device MAC address and the VLAN ID. The second line begins with the ID (serial number) of the FortiWiFi or FortiAP unit that detected the device, the AP’s MAC address, and then the fields that the Euclid service uses. Because of its length, this line wraps around and displays as multiple lines.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Using a FortiWiFi unit as a client

A FortiWiFi unit by default operates as a wireless access point. But a FortiWiFi unit can also operate as a wireless client, connecting the FortiGate unit to another wireless network.

Use of client mode Configuring client mode

Use of client mode

In client mode, the FortiWiFi unit connects to a remote WiFi access point to access other networks or the Internet. This is most useful when the FortiWiFi unit is in a location that does not have a wired infrastructure.

For example, in a warehouse where shipping and receiving are on opposite sides of the building, running cables might not be an option due to the warehouse environment. The FortiWiFi unit can support wired users using its Ethernet ports and can connect to another access point wirelessly as a client. This connects the wired users to the network using the 802.11 WiFi standard as a backbone.

Note that in client mode the FortiWiFi unit cannot operate as an AP. WiFi clients cannot see or connect to the FortiWifi unit in Client mode.

Using a FortiWiFi unit as a client                                                                                                 Use of client mode

FortiWiFi unit in Client mode

Configuring client mode                                                                                          Using a FortiWiFi unit as a client

Configuring client mode

To set up the FortiAP unit as a WiFi client, you must use the CLI. Before you do this, be sure to remove any AP WiFi configurations such as SSIDs, DHCP servers, policies, and so on.

To configure wireless client mode

1. Change the WiFi mode to client.

In the CLI, enter the following commands:

config system global set wireless-mode client

end

Respond “y” when asked if you want to continue. The FortiWiFi unit will reboot.

2. Configure the WiFi interface settings.

For example, to configure the client for WPA-Personal authentication on the our_wifi SSID with passphrase justforus, enter the following in the CLI:

config system interface edit wifi set mode dhcp config wifi-networks edit 0 set wifi-ssid our_wifi set wifi-security wpa-personal set wifi-passphrase “justforus”

end

end

The WiFi interface client_wifi will receive an IP address using DHCP.

3. Configure a wifi to port1 policy.

You can use either CLI or web-based manager to do this. The important settings are:

Incoming Interface (srcintf)	wifi
Source Address (srcaddr)	all
Outgoing Interface (dstintf)	port1
Destination Address (dstaddr)	all
Schedule	always
Service	ALL
Action	ACCEPT
Enable NAT	Selected

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Managing a FortiAP with FortiCloud

This chapter provides a few FortiCloud-managed FortiAP configuration examples.

FortiCloud-managed FortiAP WiFi

FortiCloud-managed FortiAP WiFi without a key

You can register for a free FortiCloud account at www.forticloud.com.

For a video tutorial of how to configure and manage a FortiAP-S device from FortiCloud, follow the link below:

l How to configure and Manage FortiAP-S from FortiCloud

FortiCloud-managed FortiAP WiFi

In this example, you use FortiCloud to configure a single FortiAP-221C, creating a working WiFi network without a FortiGate unit.

FortiCloud remote management is supported on FortiAP models 221C and 320C.

For this configuration, the FortiAP-221C unit is running version 5.2 firmware. You will create a simple network that uses WPA-Personal authentication.

You can register for a free FortiCloud account at www.forticloud.com.

To create the WiFi network without a FortiGate unit, you must:

l Add your FortiAP to FortiCloud l Configure the SSID l Configure the AP platform profile l Deploy the AP with the profile

Adding your FortiAP to FortiCloud

You need to add the FortiAP unit to your FortiCloud account. This is done through a unique key that can be found under the FortiAP unit.

To add a FortiAP to FortiCloud

1. Connect the FortiAP Ethernet interface to a network that provides access to the Internet.
2. Open a web browser and navigate to the FortiCloud main page and select + AP Network.
3. Enter an AP Network Name and AP Password. This password is used to locally log in to the AP as the administrator. It will be set to all APs in this AP network.
4. Set the correct Time Zone and select Submit.

Configuring the SSID

You must establish the SSID (network interface) for the WiFi network.

FortiCloud-managed FortiAP WiFi without a key                                                    Managing a FortiAP with FortiCloud

To configure the SSID

1. Select the FortiAP you just created from the home page. You will then be prompted to add an SSID for the AP Network.

In the interface, this is under Configure > SSIDs.

2. In Access Control, enter the name of your SSID, set Authentication to WPA2-Personal, enter the Preshared Key, and select Next.
3. In Security, enable security features as required (select from AntiVirus, Intrusion Prevention, Block Botnet, Web Access, and Application Control) and select Next.
4. In Availability, make sure to leave 5 GHz enabled, configure a schedule as required, and select Next.
5. Review your SSID in Preview, then select Apply.

Configuring the AP platform profile

The radio portion of the FortiAP configuration is contained in the FortiAP platform profile. By default, there is a profile for each platform (FortiAP model). The SSID needs to be specified in the profile.

To configure the AP profile

1. Go to Configure > AP Profile and edit the AP Profile for your FortiAP model (mouse-over the AP Profile to reveal the Edit button).
2. Enable the SSID configured earlier for both Radio 1 and Radio 2, for 5GHz coverage.

Deploying the AP with the platform profile

With the SSID and platform profile configured, you must deploy the AP by entering the FortiCloud key for the FortiAP.

To deploy the AP

1. Go to Configure > Deploy APs. Here you will be prompted to enter the FortiCloud key, which can be found on the same label as the FortiAP unit’s serial number, and select Submit.

If you have a FortiAP model that does not include a FortiCloud key, you can still add the device to the network. To learn how, see the FortiCloud-managed FortiAP WiFi without a key configuration.

2. In Set Platform Profiles, select the platform profile you created earlier and select Next.
3. Follow the rest of the deployment wizard. Select Submit when completed.

You will now be able to connect to the wireless network and browse the Internet. On the FortiCloud website, go to Monitor > Report where you can view monitoring information such as Traffic by Period, Client Count by Period, and more.

FortiCloud-managed FortiAP WiFi without a key

You can manage your FortiAP-based wireless network with FortiCloud even if your FortiAP has no FortiCloud key.

Managing a FortiAP with FortiCloud                                                    FortiCloud-managed FortiAP WiFi without a key

For this example, you will need to have already pre-configured your FortiAP unit with your FortiCloud account credentials. For more information on how to do this, or if your FortiAP has a FortiCloud key (on the serial number label), see the FortiCloud-managed FortiAP WiFi configuration.

You can register for a free FortiCloud account at www.forticloud.com.

To create the WiFi network without a FortiCloud key, you must:

l Configure the FortiAP unit l Add the FortiAP unit to your FortiCloud account l Configure the FortiAP

Configuring the FortiAP unit

You need to connect and configure the FortiAP unit through the web-based manager of the FortiGate.

To configure the FortiAP unit – web-based manager

1. Connect your computer to the FortiAP Ethernet port. The FortiAP’s default IP address is 192.168.1.2. The computer should have an address on the same subnet, 192.168.1.3 for example.
2. Using a browser, log in to the FortiAP as admin. Leave the password field empty.
3. In WTP-Configuration, select FortiCloud and enter your FortiCloud credentials. Select Apply.

The FortiAP is now ready to connect to FortiCloud via the Internet.

Adding the FortiAP unit to your FortiCloud account

The FortiAP must be added to the FortiCloud account that has a WiFi network already configured for it.

For an example of creating a WiFi network on FortiCloud, see FortiCloud-managed FortiAP WiFi on page 148.

To add the FortiAP to FortiCloud

1. Connect the FortiAP Ethernet cable to a network that connects to the Internet.

Restore your computer to its normal network configuration and log on to FortiCloud.

2. From the Home screen, go to Inventory > AP Inventory. Your FortiAP should be listed.
3. Then go back to the Home screen, select your AP network, and go to Deploy APs.
4. Select your listed FortiAP and select Next.
5. Make sure your platform profile is selected from the dropdown menu, and select Next.
6. In Preview, select Deploy.

The device will now appear listed under Access Points.

You will now be able to connect to the wireless network and browse the Internet. On the FortiCloud website, go to Monitor > Report where you can view monitoring information such as Traffic by Period, Client Count by Period, and more.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!