Solution |
- FortiAP AP-leave/join behavior implies the CAPWAP connection between the FortiAP and the FortiGate is resetting from time to time, causing the FortiAP join-time change (recent) as shown below:

-
The FortiGate WiFi or Wireless Event logs would show the following ap-leave/join events also the reason:
date=2024-06-26 time=13:29:24 eventtime=1719397764527603041 tz="+0300" logid="010404XXX" type="event" subtype="wireless" level="notice" vd="root" logdesc="Physical AP join" sn="FP433FTF2300XXXX" ap="Demo-AP" profile="Test-AP-profile" ip=10.30.X.X meshmode="mesh root ap" snmeshparent="N/A" action="ap-join" reason="N/A" msg="AP Demo-AP joined." date=2024-06-26 time=13:28:02 eventtime=1719397682548345461 tz="+0300" logid="010404XXX" type="event" subtype="wireless" level="notice" vd="root" logdesc="Physical AP leave" sn="FP433FTF2300XXXX" ap="Demo-AP" profile="Test-AP-profile" ip=10.30.X.X meshmode="mesh root ap" snmeshparent="N/A" action="ap-leave" reason="AC daemon reset timer expired" msg="AP Demo-AP left."
-
FortiAP exhibits ap-leave/join behavior due to the following potential reasons:
-
FortiAP kernel panic or wtpd daemon crash.
-
FortiAP and FortiGate Network connectivity issues due to latency, packet loss, bad cable, or faulty uplink switch port issues.
-
FortiAP PoE Low Power mode or random PoE switch port power loss issues.
-
FortiAP uplink Switch STP Network loop.
- FortiAP Profile is configured with 'DTLS Policy: ipsec-vpn' instead of "DTLS Policy: clear-text.
- To verify if the FortiAP or FortiGate has any relevant crash on the current firmware version:
FortiAP:
kp
crash
Alternate helpful FortiAP commands:
cw_diag kernel-panic
diag_debug_crashlog read
presult
fap-tech
FortiGate:
diag debug crashlog read
-
To verify if there are network connectivity issues between the FortiAP and the FortiGate, swap the FortiAP with a wired PC on the same switch port, run continuous pings towards the default gateway and the FortiGate AC IP address, and monitor them The 'presult' output from the FortiAP also can confirm whether the FortiAP has any packet-loss towards the AC (FortiGate IP address).
To verify whether FortiAP's current PoE power mode is full or high, use the below command:
cw_diag power
Power Detection Data: dc=0 ps1=0 af1=0 at1=0 psv1=0 bt1=0 ps2=1 af2=0 at2=1 psv2=0 bt2=0 Budget lldp 0,0 poe 0,25 (dc=99 af=13 at=25 psv=60 bt=50 full=24.9 low=24.9)
Current Power Mode: full (2) Oper Power Mode: full (2)
Radio 1: MaxTxpower 15 TxChainMask 0x0f RxChainMask 0x0f Radio 2: MaxTxpower 22 TxChainMask 0xf0 RxChainMask 0xf0 Radio 3: MaxTxpower 31 TxChainMask 0x01 RxChainMask 0x01 USB: enabled
full:usb,txpower full,chain 4; low:txpower 17,chain 2
Note:
Refer to the FortiAP datasheet, to confirm whether the FortiAP requires PoE, PoE+, or x2 802.3at PoE (Dual PoE current sharing) or 1 802.3bt PoE FortiGate, FortiEdge Cloud, or SASE-managed access points.
-
The following logs on the FortiAP can tell where the CAPWAP connection is breaking:
Collect the below logs from the affected FortiAP CLI for 5 mins:
cfg -a ADMIN_TIMEOUT=0 cfg -c
don ton
Thereafter, turn off logs:
doff toff
-
If the FortiAP does not have any crash records then the FortiAP serial console logs are required in the problem state to see if there are hardware or crash trace errors on the console.
-
On the FortiGate, verify if the following timers are default. Any non-default timers can also affect the FortiAP connection stability:
config wireless-controller global set max-retransmit 3 // Default 3 end
config wireless-controller timers set echo-interval 30 // Default 30 end
-
Ensure the FortiAP is on the latest FortiAP v7.4.5 build 0734 GA and above versions because the newer versions contain multiple kernel crash-related fixes: Resolved issues v7.4.5
|