Client connection issues

1. If the client is unable to connect to FortiAP:
   • Make sure the client security and authentication settings match with FortiAP and also check the certificates.
   • Try upgrading the Wi-Fi adapter driver, FortiGate and FortiAP firmware.
   • If other clients can connect, the issue can be with device interoperability. Run debug commands and sniffer packets.
   • Look for rogue suppression by sniffing the wireless traffic and looking for the connection issue in the output (using the AP or wireless packet sniffer).
   • Try changing the IEEE protocol from 802.11n to 802.11bg or 802.11a only.
2. If the client drops and reconnects:
   • The client might be de-authenticating periodically. Check the sleep mode on the client.
   • The issue could be related to power-saver settings. The client may need to update the 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 this configuration may be an IP conflict.
3. If the client drops and never connects:
   • The client could have roamed to another SSID. Check the standby and sleep modes.
   • 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.
   • There could be a broadcast issue. Check the WEP encryption key and set a static IP address and VLANs.

Debugging client connection issues

To see the stage at which the client fails to connect, enable the client debug on the controller for problematic clients. 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 example debug output is for the above command. This example shows the successful association phase, DHCP phase, and the 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 (0-192.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:

• Orange represents the association phase.
• Blue represents the PSK exchange.
• Green represents the DHCP phase.

It is important to note the messages for a correct association phase, four-way handshake, and DHCP phase.

Checking the WiFi password

An Administrator can view plain text passwords (captive-portal-radius-secret and passphrase) under config wireless-controller vap.

Note that security must be set as a WPA-personal setting.