WiFi Connection
To understand how WiFi clients connect to a network, we need to familiarize with two key processes. The first one is WPA supplicant, where WPA stands for ‘WiFi Protected Access’. The second one is the DHCP client, in which DHCP stands for ‘Dynamic Host Configuration Protocol’.
To illustrate how wifi connection works, the article will cover the following topics:
- 802.11 Authentication and Association
- The 4-way Handshake Phase
- WPA Supplicant
- Getting a DHCP address via D-O-R-A
- DHCP logs
- Wi-Fi monitoring with NetBeez
The WPA supplicant process handles the 802.11 Authentication and Association of the client with a BSSID. After 802.11 Authentication and Association, the 4-way handshake establishes a secure, authenticated connection between the client and the access point.
After authenticating, and associating to the network, the DHCP client requests a dynamic IP address. The client will use the IP address to connect to the network and exchange communication with the outside world.
802.11 Authentication and Association
At the beginning of the 802.11 Authentication and Association process, the client scans all of the available frequencies in search of SSIDs to join. The client sends probe request frames which contain supported data rates and 802.11 capabilities. Access points in proximity reply with probe response frames that contain the SSID and BSSID, which corresponds to the access point’s MAC address.
When the client detects an SSID matching its configuration, it initiates an authentication request probe. The authentication request and response frames remain unencrypted. The 4-way handshake that follows establishes encryption.
The authentication request and response phase records the client’s MAC address. MAC filtering can use this information if implemented. If the network permits the client to connect, it associates itself with the access point boasting the stronger signal.
Rowell Dionicio (host of ‘Clear to Send’ podcast), wrote a more detailed article on the 802.11 Authentication and Association process. Once the 802.11 Authentication and Association process completes, the WPA supplicant client initiates the 4-way handshake.
The 4-way Handshake Phase
The 4-way handshake is used to authenticate the WiFi client and encrypt all communications with the access point. The client’s WPA supplicant and the access point’s authenticator establish the handshake by exchanging EAPoL frames.
SSIDs with WPA2-Personal settings use a pre-shared key during the 4-way handshake process. SSID with WPA2-Enterprise settings execute an EAP transaction with the 802.1x authentication server (Radius).
This article won’t cover the details of how the 4-way handshake process works. Read the 4-way handshake article written by Rowell Dionicio to learn more about it. You can also read the 802.1x Wikipedia page and the page on the IANA website about EAP methods.
Once the 4-was handshake completes, the client can now request an IP address to complete the connection.
WPA Supplicant and Logs
In Linux, the 802.11 Authentication and Association and the 4-way handshake are handled by the WPA supplicant process. The following table reports the different stage transitions that the WPA supplicant process logs. The default location of the file on many Linux distributions is /var/log/wpa_supplicant/wpa_supplicant.log.
| State transition logged | Meaning |
|---|---|
| SCANNING -> ASSOCIATING | The WiFi client has completed the scan and has initiated the 802.11 Authentication and Association |
| ASSOCIATING -> ASSOCIATED | The 802.11 Authentication and Association process is completed |
| ASSOCIATED -> 4WAY_HANDSHAKE | The WiFi client has begun the 4-way handshake |
| 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE | The 4-way handshake is occurring |
| 4WAY_HANDSHAKE -> GROUP_HANDSHAKE | The 4-way handshake is completed and the exchange of the group keys has begun |
| GROUP_HANDSHAKE -> COMPLETED | The group keys exchange is completed |
This article by Panos Vouzis explains how to read WPA logs in Linux
Getting a DHCP address via D-O-R-A
Once the 4-way handshake completes, the client moves to the “network phase” of the connection to request a dynamic IP address. Getting a DHCP address for WiFi clients is the same process as it is for Ethernet ones. The DHCP transaction between the DHCP client and the server is called D-O-R-A. This acronym relates to the frames exchanged during the transaction between client and server (see below image).
The transaction begins with a DHCP discovery frame. Here, the DHCP client sends broadcasts to all the hosts in the local subnet. If a DHCP server is available, it replies with a DHCP offer that contains an IP address available for use.
Then, the client verifies with an ARP lookup that no other hosts are using the address offered by the server. If no other host replies to the ARP request, the client confirms the intent to use that IP with a DHCP request. The DHCP server acknowledges the IP address confirming with a DHCP acknowledgement. That marks the end of the D-O-R-A transaction.
Reading DHCP logs
This section will help you troubleshoot DHCP issues on a WiFi client running Linux. I recommended that you configure the dhclient to log messages on /var/log/dhcpd.log rather than sending them to syslog. This way, it will be easier to review DHCP logs.
In the dhcpd.log, you’ll find messages containing the following strings for the D-O-R-A transaction:
- DHCPDISCOVER
- DHCPOFFER
- DHCPREQUEST
- DHCPACK
The DHCP state machine exchanges these D-O-R-A messages while it’s in the PREINIT to BOUND stage transition. Here’s a list of the most important DHCP stages that will help you troubleshoot what’s going with the DHCP process.
| Stage | Meaning |
|---|---|
| PREINIT | In this state, the DHCP client is initializing. |
| BOUND | The client has obtained a DHCP lease. |
| RENEW | The client is trying to renew its DHCP lease. |
| REBIND | The client didn’t renew the lease on time and requests a lease extension to any available server. |
| TIMEOUT | The client timed out and didn’t get a DHCP lease from a server. |
| FAIL | The client failed to obtain a DHCP lease for some other reasons. |
If you want to learn more about DHCP messages, check out the IANA page on DHCP. For more information about the DHCP stages, check out the online TCP/IP guide on DHCP.
Test WiFi Connection Timing with NetBeez
NetBeez offers an effortless method for WiFi network monitoring. The dashboard collects real-time data from wireless sensors that connect to one or multiple SSIDs. The Wi-Fi sensors test the connection, measure the time it takes, and logs the signal strength and other statistics. Within the NetBeez dashboard, you can examine the entire WiFi connection timing procedure, categorized into phases: association, authentication, and DHCP.
Each test also provides detailed logs from the WPA client supplicant and DHCP client processes. In the following screenshot you can read the log of the WPA Supplicant client.
In the next screenshot, I have filtered the DHCP messages logged when a WiFi Beez is requesting a DHCP address. You can easily identify the D-O-R-A transaction between the Beez and the access point.
Conclusion
A Wi-Fi client connects by scanning for Wi-Fi networks and receiving responses. It then starts the 802.11 authentication and association process, recording the MAC address. The 4-way handshake creates a secure connection, and the client gets an IP address through DHCP to access the network.
In Wi-Fi monitoring, engineers set up WLAN agents to detect Wi-Fi connection problems. These agents reconnect to the network at regular intervals. They test 802.11 authentication, association, and DHCP.
NetBeez is a Wi-Fi monitoring solution that provides a simple to use dashboard with plug and play wifi sensors. Request a free trial or a demo to learn more.
