Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.

FortiAP performance very poor (Wifi to Internal networks)

Hi All,


We have noticed a performance issue with FortiAP's e.g 221C's when pinging a server on the internal network. 

We are seeing erratic ping response times from laptops or other mobile devices pinging devices on other networks. (both internal and internet)

This is not limited to a single installation, but across multiple sites with different model Fortigates and AP's 


Also seeing errors like this also despite the fact the AP is connected to the Fortigate Firewall so no congestion. (Firewall is the controller


   last failure     : 14 -- ECHO REQ is missing
    last failure param: N/A



We are running the latest firmware 5.4.1 on all Firewalls and AP's and have tried many of the various "things to try" that we have found on the Forums etc but no good. (correct country settings, tried all the MTU suggestions etc etc)

Ping response times are all over the place e.g 120ms pinging a server on an internal VLAN.  (should be 2ms)

We turned off all UTM etc from wifi to internal and no good either.


Anyone any suggestions ?









Esteemed Contributor III

Have you compared the ping results between 1) WiFi-client and WiFi-GW(FG), 2) WiFi-GW(FG) and the server on the LAN, and 3) WiFi-client and the server on the LAN(you already did)? It would give you some idea where the delay/packet losses are occurring.


Have you tested by creating SSIDs for only 2.4GHz and 5GHz and compared? Is the latency seen only on 2.4GHz?

New Contributor

We had the same issue about the ECHO REQ missing and I applied :


config wireless-controller timers set echo-interval 120


FGT sends echos to the FortiAPs and if the FGT doesn't get an echo reply for the x intervals it will put the AP down for some time. Never had the issue since then. But response time won't be 2ms over wifi. Maybe you have too much broadcast trafic between AP and FGT?


Hope it helps.

Fortigate : 80E, 80F, 100E, 200F, 300E : 6.4.6

FortiAnalyzer, ForticlientEMS

Fortigate : 80E, 80F, 100E, 200F, 300E : 6.4.6 FortiAnalyzer, ForticlientEMS
Valued Contributor

check the systems tcp-mss-sender and receiver settings too (for the wifi controller) fragments are common because of the capwap tunnel

Mike Pruett Fortinet GURU | Fortinet Training Videos

Hi all


Just wanted to give some feedback here.


The issue in this case appears to be related to the incorrect country code set on the AP's.

A global country code setting was applied, but perhaps it was not before the AP's were connected/ detected by the Fortigate. (Looks like the AP's used the default country settings)

This should not matter too much I expect as the mobile device should work in any country I would have thought. However the problem was the site had some legacy standalone AP's (non Fortinet) also using the same SSID. 


It appeared that the FAP was not transmitting the SSID's.

Perhaps because the laptop was connecting to a low signal channel on one of the standalone AP's (was some distance away, hence the latency etc)

Why did the AP appear not to be transmitting ? We dont know, in theory a laptop should connect to an AP in any country...however it might have got confused when it saw two AP's each with different country settings and decided to completely ignore one of them?


We ended up creating a new profile for the AP with the correct country settings and now it seems ok.









As for country code, when AP's country code doesn't match the settings on the controller, SSID might not be broadcasted by AP.  For example. If you have an AP with UK region but has country code set to U.S on the controller,  VAP would not come up depending on the channel selected, 165 for example.  This is enforced according to regulation



Top Kudoed Authors