Users complaining of intermittent wifi issues (wifi connected / internal resources lost)

[ggntt]

Hi all

We have a site with a FG 60D with a few FP221c's

The FGT is running version 5.4.1 build 5447

Users are complaining that they are having intermittent wireless connectivity issues.

They noted the following

The wireless remains connected, but access to the internet and internal resources is lost and later returns. 

They verified that when connected to the wired network they are not having any issues.

This could happen several times a week.

Anyone experience this issue ?

Thanks

ggntt

[Toshi_Esumi]

Do the clients lose pinging to the wifi GW IP or see extreme slowdown (like 800ms-1200ms) at that time? We experienced similar (wifi slowdown and lockup) but with FWF60D+5.2.x+2.4GHz. After upgraded it to 5.4.1 it stopped happening. We have FG60D+FAP221B environment as well but it never exhibited the same symptom.

[eti_andrei]

We are experiencing the same issue at a client site, except with a FG 1500D running 5.4.1 and ninety S321C access points.

So far, it seems as if iOS and macOS devices are affected the most. Some will drop off only to reconnect and have no traffic - internal or external - pass through. We downgraded the AP firmware to the previous build, but issues still persist. Currently working with TAC on this issue.

[ggntt]

Hi Eti

We have made a few changes that fixed this issue for us on a few sites.   (Item 3 below is the biggest problem) 

1. Make sure your country is set to the appropriate country

Fortigate # config wireless-controller setting Fortiage (setting) # show config wireless-controller setting set country US end Fortigate (setting) #

2.  Change the default timers

Fortigate # config wireless-controller timers Fortigate (timers) # show config wireless-controller timers set echo-interval 100 end Fortigate (timers) #

Fortigate # config wireless-controller global Fortigate (global) # show config wireless-controller global set max-retransmit 15 end Fortigate (global) #

3. Turn off DARRP (This appears to alter change channels when users are connected / causing the drop offs)

Fortigate # config wireless-controller wtp-profile

If you type show, it will show you the configuration of all the various AP profiles for every different model of AP.

In this case we are using the FAP221C model of AP’s, so we are going to go ahead and edit that profile.

Fortigate (FAP221C-default) # config radio-1 Fortigate (radio-1) # set darrp disable

(you need to turn it off for both radios)

Fortigate (wtp-profile) # edit FAP221C-default Fortigate (FAP221C-default) # config radio-2 Fortigate (radio-2) # set darrp disable

N.B If you connected an AP to the Fortigate before you changed the global country setting the AP appears to use that country setting even after you change the global country setting.

Make sure that the AP profile has the correct country settings also.  

(FAP221C-default) # show

config wireless-controller wtp-profile

    edit "FAP221C-default"

        config platform

            set type 221C

        end

        set ap-country US

[eti_andrei]

Thank you so much for this follow-up! We already stumbled on some of these fixes ourselves, but I'm glad you were able to corroborate them.

There were some peculiarities with WIDS that we also noticed. At one point, WIDS had been enabled on some radios and a few rogue APs were identified and blacklisted. Though WIDS was disabled and removed from the AP profiles, we noticed the AP radios were still in rogue detection mode. It was only when we purged the WIDS blacklist (via the CLI) that everything seemed to work normally again. Once I have some time, I will further test this behavior.

[tanr]

@ggntt,

Useful stuff, thanks.  I've been seeing something similar, with brief times where the client's wifi connection shows as fine but no communication going through.  I'm only seeing it with clients who are running VPN connections through the (bridged, not tunneled) wifi.  I'll try out your suggestions tomorrow and see if it helps.

One question, though.  Do you know why increasing the echo-interval is supposed to help?

[ggntt · Accepted solution]

No problem

From the command output # diag wireless-controller wlac -c wtp we saw the following type of errors last failure : 14 -- ECHO REQ is missing and this is repeated across a few sites despite the fact that there was little or no traffic on the network / vlan we also saw last failure : 8 -- AC daemon reset timer expired and last failure : 4 -- Control message maximal retransmission limit reached These are all instances of failure due to CAPWAP keep alive being missed: "15 ECHO REQ is missing" was logged if the controller could not receive echo req from the FAP. "4 Control message maximal retransmission limit reached" was logged if the controller sent a control message to the FAP, but did not receive the resp message. The above messages imply that the FGT (AC controller) and the FortiAP are having difficulty in communicating at times. This may happen if, for example, if there is too much broadcast / multicast traffic on the link between the AP's and the controller.  (But we sometimes saw the messages when there was very little traffic)

We then increased the keep alive timers as follows  # config wireless-controller global # set max-retransmit 3 <<<<---- default - please input integer value (0-64) we increased to 15 and # config wireless-controller timers # set echo-interval 30 <<<<---- default - please input integer <1-255> we increased to 100 # end

[tanr]

Very helpful, thanks ggntt!