WiFi Connection
To better understand how a WiFi clients connect to a wireless network, it’s worth familiarizing yourself with two client processes. The first one being WPA supplicant. WPA stands for ‘WiFi Protected Access’. The second one is the DHCP client, in which DHCP stands for ‘Dynamic Host Configuration Protocol’. Let’s see how these two system processes come into play. This 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
- Timing WiFi connection with NetBeez
The WPA supplicant process handles the 802.11 Authentication and Association of the client with a BSSID. The 802.11 Authentication and Association is then followed by the 4-way handshake, which establishes a secure and authenticated channel 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 purpose of the authentication request and response phase is to record the client’s MAC address, which also proves useful in the event of MAC filtering implementation. If the network permits the client to connect, it associates itself with the access point boasting the stronger signal.
Our friend, 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 handshake is established by exchanging EAPoL frames between the WPA supplicant running on the client and the authenticator running on the access point.
If the SSID is configured with WPA2-Personal, the 4-way handshake uses a pre-shared key. If the SSID is configured with WPA2-Enterprise, the client will also execute an EAP transaction with an 802.1x authentication server (Radius). Here, I won’t cover in detail how the 4-way handshake process works, but if you want to learn more about the 4-way handshake, I have linked another article written by Rowell Dionicio. If you want to learn more about 802.1x, check out 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 WiFi 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 are logged by WPA supplicant. 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 |
If you want to learn more about reading WPA logs in Linux, check out the article I have linked written by Panos Vouzis.
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 will reply with a DHCP offer containing an IP address available for use. The client then verifies with an ARP lookup that no other hosts are improperly 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 system utilizes wireless sensors that link to one or multiple SSIDs, assess the connection, and measure the time it takes. 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.
We recorded a short demo video that explains how WiFi connection works.
Conclusion on WiFi Connection
Familiarizing yourself with the WPA supplicant and DHCP client processes is important to understand how 802.11 networks work. To proactively detect problems on WiFi networks, engineers can configure dedicated WLAN agents to periodically reconnect to the network, testing 802.11 authentication and association, as well as DHCP.
