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.