EAPOLs in Linux Wireless Extensions

[Jouni Malinen]

On Wed, Nov 16, 2005 at 10:39:16AM +0200, Bar, Eitan wrote:

> Can somebody please describe the chain of events in the kernel/user-mode (as far as WEXT IOCTLs and events) that occur when a station associates and starts the EAPOL handshake?

Start is different based on ap_scan configuration:

ap_scan=1:

- wpa_supplicant requests scan with SIOCSIWSCAN
- driver reports scan complete with wireless event SIOCGIWSCAN
- wpa_supplicant reads scan results with SIOCGIWSCAN (multiple call if
  a larget buffer is needed)
- wpa_supplicant decides which AP to use based on scan results
- wpa_supplicant configures driver to associate with the selected BSS
  (SIOCSIWMODE, SIOCSIWGENIE, SIOCSIWAUTH, SIOCSIWFREQ,
   SIOCSIWESSID, SIOCSIWAP)

ap_scan=2:

- wpa_supplicant configures driver to associate with an SSID
  (SIOCSIWMODE, SIOCSIWGENIE, SIOCSIWAUTH, SIOCSIWESSID)


After this, both modes use similar steps:

- optionally (or required for drivers that generate WPA/RSN IE for
  (Re)AssocReq), driver reports association parameters (AssocReq IEs)
  with wireless event IWEVASSOCREQIE (and optionally IWEVASSOCRESPIE)
- driver reports association with wireless event SIOCGIWAP
- wpa_supplicant takes care of EAPOL frame handling (validating
  information from associnfo and if needed, from scan results if WPA/RSN
  IE from the Beacon frame is not reported through associnfo)

> What I?m specifically interested in is how the kernel driver makes sure that only EAPOL packets are sent/received by the driver and how can the network stack (or whoever) makes sure EAPOLs are prioritized over other types of traffic. (What happens if at the moment the interface notifies ?UP?, the network stack starts sending heavy traffic).

Currently, the wlan driver is expected to take care of this, i.e., it
should filter out non-EAPOL frames if IEEE 802.1X/WPA/WPA2
authentication has been configured, but encryption keys are not yet
configured. set_drop_unencrypted() driver_ops handler can be used to
configure this behavior for the driver.

As far as packet scheduling is concerned, the wlan driver would be
responsible for using higher priority (e.g., VO category with WMM) for
EAPOL frames.

> Will this traffic be just dropped at some higher level of the kernel driver and handle only EAPOLs? (I am aware of a driver wrapper to handle only EAPOLs, but what I?m concerned is other traffic from network stack and what happens to it).

In the current implementation, that traffic would likely be sent to the
driver and the driver would be responsible for dropping non-EAPOL
frames.

> Is there maybe a special support to notify the linux networking stack that it should not forward any packets other than EAPOLs?

I haven't looked at the current IEEE 802.11 stack code in Linux 2.6.14,
but in theory, this kind of functionality could happen in the generic
802.11 code. However, if you need to support something older than Linux
2.6.14 or if you are not using the 802.11 code from kernel tree
(net/ieee80211), the driver better be prepared for handling this.

-- 
Jouni Malinen                                            PGP id EFC895FA