Architecture Overview
DSA Supplicant is designed to be a "daemon" program that runs in the background and acts as the backend component controlling the wireless connection. DSA Supplicant supports separate front-end programs; a sample GUI and an example text-based front-end, wpa_cli. Both are included with DSA Supplicant.
The following steps are used when DSA Supplicant is associated with an Access Point using WPA. This example uses DSA Supplicant to control AP selection:
- DSA Supplicant requests the kernel driver to scan neighboring access points, identified by their basic service sets (BSSs)
- DSA Supplicant selects a BSS that the client has been configured to work with
- DSA Supplicant sends a request to the kernel driver to associate with the chosen BSS
- If the BSS is using WPA-EAP, DSA Supplicant completes authentication with the authentication server. (The access point proxies the authentication.) The master key is derived during handshake authentication.
- If the BSS is using WPA-PSK, DSA Supplicant uses PSK as the master session key. The client then completes the WPA 4-Way Handshake and Group Key Handshake with the authenticator, that is, the access point itself rather than an authentication server.
- DSA Supplicant configures encryption keys for unicast and broadcast. Normal data packets can now be transmitted and received.
Event-Driven Application Model
DSA Supplicant uses a single-process, event-loop model. The event loop allows the DSA Supplicant to provide callbacks on relevant events, such as registered timeout, received packet, signal strength, and so on.
Different operating systems provide different methods of notification for network events. You can, however, use the DSA Supplicant loop interface to capture events through whatever means dictated by an operating system.
As shown in Figure 1: Devicescape Agent Supplicant Architecture, DSA Supplicant has four high-level interfaces that can be used to customize your wireless client, add support for new hardware, or port your wireless client to a different operating system. For WinCE and Windows Mobile, DSA Supplicant has an additional internal IM (Intermediate) driver interface that allows DSA Supplicant to be with used without removing Windows Zero Config (WZC).
Porting to a new operating system may result in a wireless client that has a slightly different architecture than shown in this figure.
Figure 1 Devicescape Agent Supplicant Architecture
The Driver Interface
The DSA Supplicant API provides a well-defined driver interface. When porting to a new operating system, you typically use this interface to write a driver wrapper. Once you have implemented a driver wrapper for a particular operating system, you can often use this wrapper for all devices that the operating system supports, with little or no further modification. The driver interfaces includes multiple implementations. These implementations have been tested on WinCE with NDIS and on Linux with Broadcom BCM4320 and Atheros AR6000.
The Network Stack Interface
Different operating systems provide different levels of support for network protocols and provide access to network traffic in different ways. The network interface stack allows you to adapt DSA Supplicant to different operating systems. Using the stack, you can take advantage of existing services offered by a particular operating system. When required services are not available, you can use the network stack interface to implement them.
Transport Layer Security (TLS) Interface
The Transport Layer Security (TLS) interface allows you to use different TLS libraries with DSA Supplicant without having to modify the core modules of the supplicant.
The DSA Supplicant TLS interface allows you to use the TLS library that conforms to your needs. You can, for example, use TLS libraries that are designed for memory constrained environments (such as the Certicom and PeerSec Networks libraries). For applications that are not so constrained, you can also use the OpenSSL TLS, which is provided with DSA Supplicant. For more detailed information on supported TLS solutions, see TLS Interface.
Control Interface
The control interface allows you create configuration interfaces or use configuration services. You can, for example, build a graphical user interface to configure the client. You can also use the interface to enable DSA Supplicant to take advantage of automatic configuration services (such as a configuration agent).
DSA Supplicant implements configuration and management interfaces (control interface) that can be used by external programs to control the operations of the wpa_supplicant daemon and to get status information and event notifications.
The Reference Documentation for the control interface describes the interfaces provided for writing configuration applications and using configuration agents. It also describes a list of control interface commands that can be used with the wpa_ctrl_request().
For more detailed information, see the Control Interface section in the API Reference Documentation.
NDIS Intermediate (IM) Driver Interface (dsfilter.dll)
The IM Driver (dsfilter.dll) is only for Windows Mobile and WinCE. The IM driver included in DSA Supplicant has two operation modes:
The dsfilter.dll IM driver is initialized in WZC mode by default, and moves to DSA mode when the DSA Supplicant application/service is started. When the DSA Supplicant application/service is terminated, dsfilter.dll moves to WZC mode. The virtual adapter is rebound when the mode changes so that a reboot is not needed to change between different supplicants.
For both modes, a new virtual adapter, such as, DSFLTR_AR6K1, is created. The physical adapter (e.g., AR6K1) is only bound to DSFLTR and NDISUIO/TCPIP/TCPIP6 protocols are bound to the virtual adapter (DSFLTR_AR6K1). This means that the upper levels of the networking stack are using the virtual miniport instead of the physical miniport.
When the IM driver is in Windows Zero Configuration (WZC) mode, it does not perform additional filtering of packets (e.g., EAPOL frames to the supplicant) and most of the OID operations are passed to the physical miniport (with the power management and capability query being main exceptions since the IM driver need to do additional processing on them). This means that the virtual adapter shows up as a wireless interface, enabling WZC and wireless manager to control it.
When in DSA Supplicant mode, the IM driver thecaptures EAPOL and RSN pre-authentication packets and passes them to the supplicant. In addition, the interface type is changed from wireless to wired. This prevents WZC from controlling the interface while supplicant is used.
NDIS 802.11 Object Identifiers
DSA Supplicant on WinCE, Windows Mobile, and Windows XP will function best with a robust NDIS Object Identifier (OID) set and query implementation at the miniport driver level. A summary of the OIDs utilized in this implementation is provided below. If you are a miniport driver writer, you should ensure that your driver implements most, if not all, of the following OIDs.
- OID_802_11_AUTHENTICATION_MODE
- OID_802_11_ENCRYPTION_STATUS
- OID_802_11_BSSID
- OID_802_11_SSID
- OID_802_11_DISASSOCIATE
- OID_802_11_BSSID_LIST_SCAN
- OID_802_11_BSSID_LIST
- OID_802_11_REMOVE_KEY
- OID_802_11_REMOVE_WEP
- OID_802_11_ADD_WEP
- OID_802_11_ADD_KEY
- OID_802_11_INFRASTRUCTURE_MODE
- OID_802_11_PRIVACY_FILTER
- OID_802_11_PMKID
- OID_802_11_ASSOCIATION_INFORMATION
- OID_802_11_CAPABILITY
- OID_802_3_CURRENT_ADDRESS
The NDISUIO driver interface will attempt to determine as much WLAN miniport driver capability information as possible from other OIDs if the OID_802_11_CAPABILITY OID is not implemented, but it is preferable that this OID be implemented by the miniport driver developer. More information can be obtained at Microsoft's developer website, http://msdn.microsoft.com.
