Heres what happens as I see it on capture files:
Step 1
When a STA wants to access an existing BSS (either after power up, sleep mode or simply just entering the RF BSS domain), the station needs to get synchronisation information from the AP.
It can get this information by one of two ways:
Passive scanning of the RF: STA just waits and received Beacon frames from the AP(s) sent periodically by all APs with the synchronisation information
Active scanning: The STA tries to actively find an AP by transmitting a probe request frame which can either contain the name of the SSID it wants to connect to, or I believe the probe request can be a broadcast to allow all APs to send their SSIDs back in probe responses (Excerpt from the definite guide: Probe Requests: This may be set to the SSID of a specific network or set to join any compatible network. Drivers that allow cards to join any network use the broadcast SSID in Probe Requests.)
Note: The AP responds with its security capabilities in the RSNIE field of the Probe Response frame if you have configure dot1x on the WLAN; this includes all of its enabled encryption and authentication capabilities etc etc etc, if you have a guest WLAN with web-auth, there is no RSN field. Also, the probe response do all the usual 802.11 management stuff like advertised data rates, ssid, QoS etc etc etc
Step 2
When the STA receives the Probe Response or desire beacon frame, it performs open system authentication
—null authentication—with the AP. The purpose of this frame sequence, which provides no security, is simply to maintain backward compatibility with the IEEE 802.11 state machine, as implemented in existing IEEE 802.11 hardware.
Step 3
Now the station sends a the all important packet to try to connect to the selected AP and thus BSS. It sends the association Request. In the frame is contains the RSN tagged data that should match that of the RSNIE in the prevision probe response.
Step 4.
The AP send back an association response. This frame has a field in the fixed parameters that either says Successful Status code 0x0000 and an association ID or some other value which im not sure of at this time.
The STA and AP are Connected.
Step 5.
Optionally, the STA can send an EAPOL start which is fired off to the AP, LWAPPed up to the WLC. This is the STA starting the real authentication process, (not that that is describe in step 2 above). Like I say, this is optional, if the STA does not send this packet, the WLC just sends an EAP-Identity request. Sometimes you see a WLC eap-identity request come into the STA before it has had a chance to send the option al EAPOL start frame to the WLC. EAPOL-start packet contains just a 802.1x start message. The STA is saying lets start the 802.1x handshake. Eap-Reqest ID packets just contain the SSID and WLC identity
Step 6.
STA now has to send its identity to the WLC. Basically, hostname, device name etc etc. Again, this is LWAPPed up to the WLC and now the WLC forwards this packet encapsulated/converted ina Radius access-request packet to the configured RADIUS server on the WLAN.
Step 7.
Radius server sends a Radius packet to the WLC which now converts it into an eap-request packet (just the same as the eap-packet in step 5) and the WLC fires that down to the client. The difference in the eap-reuqest packet in this step as supposed to the one in step 5, is that it is not an eap-request identify (type 1), it is an eap-request protocol packet, ie type code 13 for EAP-TLS.
Step 8.
EAP-Exchange, ei, EAP-TLS, EAP-PEAP between STA and Radius Server via WLC. If good, get an eap-success from Radius server to STA, if bad, EAP-Failure message.
Step 9.
WLC and STA now build session keys and this is the EAPOL Four-way handshake between STA and WLC.
Step10 (at last)
Get a DHCP IP address hopefully
HTHs
