Troubleshooting Connection issues

Leave a reply

Connection issues

If the client has a connectivity issue that is not due to signal strength, the solution varies by the symptom.

Client connection issues

  1. If client is unable to connect to FortiAP:
    • Make sure the client’s security and authentication settings match with FortiAP and check the certificates as well. l Try upgrading the Wi-Fi adapter driver and FortiGate/FortiAP firmware. l If other clients can connect, it could be interoperability; run debug commands and sniffer packets.
    • Look for rogue suppression by sniffing the wireless traffic and looking for the disconnect in the output (using the AP or wireless packet sniffer). l Try changing the IEEE protocol from 802.11n to 802.11bg or 802.11a only.
  2. If the client drops and reconnects:

Connection

  • The client might be de-authenticating periodically. Check the sleep mode on the client. l The issue could be related to power-saver settings. The client may need to udpate 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 it may be an IP conflict.
  1. If the client drops and never connects:
    • It could have roamed to another SSID, so check the standby and sleep modes. l You may need to bring the interface up and down.
  2. If the client connects, but no IP address is acquired by the client:
    • Check the DHCP configuration and the network. l It could be a broadcast issue, so check the WEP encryption key and set a static IP address and VLANs.

Debug

You should also enable client debug on the controller for problematic clients to see the stage at which the client fails to connect. 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 is a sample debug output for the above command, with successful association/DHCP phases and 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 (0192.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:

l orange represents the association phase, l blue represents the PSK exchange, l and green represents the DHCP phase.

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

FortiAP connection issues

Clients are not the only device that can fail to connect, of course. A communication problem could arise from the FortiAP.

Some examples include:

  • The FortiAP is not connecting to the wireless controller. l One FortiAP intermittently disconnects and re-connects. l All FortiAPs intermittently disconnect and re-connect. l Unable to Telnet to FortiAP from controller/administrator workstation.

In the above cases:

  • Check networking on the distribution system for all related FortiAPs.
  • Check the authorization status of managed APs from the wireless controller.
  • Restart the cw_acd process (Note: All APs will drop if you do this, and you may be troubleshooting just one AP).
  • Check the controller crash log for any wireless controller daemon crash using the following command:

diagnose debug crashlog read

Debug

For a quick assessment of the association communication between the controller and the FortiAP, run the following sniffer command to see if you can verify that the AP is communicating to the controller by identifying the CAPWAP communication: diagnose sniff packet <interface_name> “port 5246” 4

If you do not see this communication, then you can investigate the network or the settings on the AP to see why it is not reaching the controller.

The following command allows you to collect verbose output from the sniff that can be converted to a PCAP and viewed in Wireshark.

Connection

diagnose sniff packet <interface_name> “port 5246” 6 o l

The image below shows the beginning of the AP’s association to the controller. You can see the discovery Request and Response at the top.

Throughout debugging it is recommended to:

  • Enable Telnet login to the FortiAP device so that you can log in and issue local debugging commands:

config wireless-controller wtp edit “<FortiAP_serial_number>” set override-allowaccess {disable|enable}

set allowaccess {telnet | http | https | ssh}

end l Try to connect to the wireless controller from the problematic FortiAP to verify routes exist.

  • Enable wtp (FortiAP) debugging on the wireless controller for problematic FortiAPs to determine the point at which the FortiAP fails to connect:

diag wireless-controller wlac wtp_filter FP112B3X13000193 0-192.168.6.8:5246 2

(replace the serial number and IP address of the FortiAP) di de console timestamp en di de application cw_acd 0x7ff di de en

Example of a successful AP and controller association:

The previous debug command provides similar output to the sample debug message below for a successful association between the FortiAP and the wireless controller. This includes the elements of the CAPWAP protocol; the Request, Response, DTLS, Join, and Configuration (identified in color). All of these are bi-directional, so if the DTLS response is slow, it may be an example of a configuration error.

56704.575 <msg> DISCOVERY_REQ (12) <== ws (0-192.168.35.1:5246) 56704.575 <msg> DISCOVERY_RESP (12) ==> ws (0-192.168.35.1:5246) 56707.575 <msg> DISCOVERY_REQ (13) <== ws (0-192.168.35.1:5246)

56707.575 <msg> DISCOVERY_RESP (13) ==> ws (0-192.168.35.1:5246) 56709.577 <aev> – CWAE_INIT_COMPLETE ws (0-192.168.35.1:5246)

56709.577 <aev> – CWAE_LISTENER_THREAD_READY ws (0-192.168.35.1:5246)

56709.577 <fsm> old CWAS_START(0) ev CWAE_INIT_COMPLETE(0) new CWAS_IDLE(1)

56709.577 <fsm> old CWAS_IDLE(1) ev CWAE_LISTENER_THREAD_READY(1) new CWAS_DTLS_SETUP(4)

56709.623 <aev> – CWAE_DTLS_PEER_ID_RECV ws (0-192.168.35.1:5246)

56709.623 <aev> – CWAE_DTLS_AUTH_PASS ws (0-192.168.35.1:5246)

56709.623 <aev> – CWAE_DTLS_ESTABLISHED ws (0-192.168.35.1:5246)

56709.623 <fsm> old CWAS_DTLS_SETUP(4) ev CWAE_DTLS_PEER_ID_RECV(7) new CWAS_DTLS_ AUTHORIZE(2)

56709.623 <fsm> old CWAS_DTLS_AUTHORIZE(2) ev CWAE_DTLS_AUTH_PASS(3) new CWAS_DTLS_CONN(5)

56709.623 <fsm> old CWAS_DTLS_CONN(5) ev CWAE_DTLS_ESTABLISHED(8) new CWAS_JOIN(7)

56709.625 <msg> JOIN_REQ (14) <== ws (0-192.168.35.1:5246)

56709.625 <aev> – CWAE_JOIN_REQ_RECV ws (0-192.168.35.1:5246)

56709.626 <fsm> old CWAS_JOIN(7) ev CWAE_JOIN_REQ_RECV(12) new CWAS_JOIN(7)

56709.629 <msg> CFG_STATUS (15) <== ws (0-192.168.35.1:5246)

56709.629 <aev> – CWAE_CFG_STATUS_REQ ws (0-192.168.35.1:5246)

56709.629 <fsm> old CWAS_JOIN(7) ev CWAE_CFG_STATUS_REQ(13) new CWAS_CONFIG(8)

56710.178 <msg> CHG_STATE_EVENT_REQ (16) <== ws (0-192.168.35.1:5246)

56710.178 <aev> – CWAE_CHG_STATE_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.178 <fsm> old CWAS_CONFIG(8) ev CWAE_CHG_STATE_EVENT_REQ_RECV(23) new CWAS_DATA_ CHAN_SETUP(10)

56710.220 <aev> – CWAE_DATA_CHAN_CONNECTED ws (0-192.168.35.1:5246)

56710.220 <msg> DATA_CHAN_KEEP_ALIVE <== ws (0-192.168.35.1:5246)

56710.220 <aev> – CWAE_DATA_CHAN_KEEP_ALIVE_RECV ws (0-192.168.35.1:5246)

56710.220 <msg> DATA_CHAN_KEEP_ALIVE ==> ws (0-192.168.35.1:5246)

56710.220 <fsm> old CWAS_DATA_CHAN_SETUP(10) ev CWAE_DATA_CHAN_CONNECTED(32) new CWAS_ DATA_CHECK(11)

56710.220 <aev> – CWAE_DATA_CHAN_VERIFIED ws (0-192.168.35.1:5246)

56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_KEEP_ALIVE_RECV(35) new CWAS_ DATA_CHECK(11)

56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_VERIFIED(36) new CWAS_RUN(12)

56710.228 <msg> WTP_EVENT_REQ (17) <== ws (0-192.168.35.1:5246)

56710.228 <aev> – CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.228 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56710.230 <msg> CFG_UPDATE_RESP (1) <== ws (0-192.168.35.1:5246) rc 0 (Success)

56710.230 <aev> – CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)

56710.230 <msg> WTP_EVENT_REQ (18) <== ws (0-192.168.35.1:5246)

56710.230 <aev> – CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.230 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)

56710.230 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56710.231 <msg> WTP_EVENT_REQ (19) <== ws (0-192.168.35.1:5246)

56710.231 <aev> – CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.231 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56710.232 <msg> CFG_UPDATE_RESP (2) <== ws (0-192.168.35.1:5246) rc 0 (Success)

56710.232 <aev> – CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)

56710.232 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)

56710.233 <msg> WTP_EVENT_REQ (20) <== ws (0-192.168.35.1:5246)

56710.233 <aev> – CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)

56710.233 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)

56712.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 3 dbg 00000000 pkts 12493 0 56715.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 6 dbg 00000000 pkts 12493 0 56718.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 9 dbg 00000000 pkts 12493 0

56719.253 <aev> – CWAE_AC_ECHO_INTV_TMR_EXPIRE ws (0-192.168.35.1:5246)

56719.253 <fsm> old CWAS_RUN(12) ev CWAE_AC_ECHO_INTV_TMR_EXPIRE(39) new CWAS_RUN(12)

 

General problems

56719.576 <msg> ECHO_REQ (21) <== ws (0-192.168.35.1:5246)

56719.576 <aev> – CWAE_ECHO_REQ_RECV ws (0-192.168.35.1:5246)

56719.577 <fsm> old CWAS_RUN(12) ev CWAE_ECHO_REQ_RECV(27) new CWAS_RUN(12)

where:

l orange represents the Discovery phase, l blue indicates that the control channels have been established using DTLS, l green represents the access point Discovery and Join phase, l purple represents the Clear Text channel, l and pink indicates that the FortiAP successfully connected to the wireless controller.

This entry was posted in Administration Guides, FortiAP, FortiOS 5.6 on by .

About Mike

Michael Pruett, CISSP has a wide range of cyber-security and network engineering expertise. The plethora of vendors that resell hardware but have zero engineering knowledge resulting in the wrong hardware or configuration being deployed is a major pet peeve of Michael's. This site was started in an effort to spread information while providing the option of quality consulting services at a much lower price than Fortinet Professional Services. Owns PacketLlama.Com (Fortinet Hardware Sales) and Office Of The CISO, LLC (Cybersecurity consulting firm).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.