Wi-Fi Authentication Tests (Compact 2013)
3/26/2014
For a Windows Embedded Compact device that connects to a network in infrastructure mode, the tests in the Wi-Fi Authentication Test Suite validate proper operation by exercising all valid combinations of the authentication and encryption protocols for the device in relation to an access point (AP). Additionally, these tests help ensure that the Windows Embedded Compact device does not connect to an AP when the configuration is incorrect.
To validate that a Wi-Fi station can connect to the appropriate access point (AP) through each valid combination of authentication and encryption protocols, you must test all of these connections. In addition, you must test to ensure that a Windows Embedded Compact powered device does not connect to any AP for which the device is not configured.
The Wi-Fi Authentication Tests requires three servers: the AP Control server, the Remote Authentication Dial-in User Service (RADIUS) server (commonly known as the Authentication Authorization Accounting (AAA) server), and the Dynamic Host Control Protocol (DHCP) server. You can choose to install all of these servers on the same computer, or you can install them on separate computers. The following illustration shows an example of a test network configuration.
The AP Control server handles access point configuration requests from the device that is being tested and updates the APs to the required security modes. This server must run both the UDP and TCP Echo services to allow the device to verify a wireless connection.
The RADIUS server stores a list of clients, that is, the access points which connect to it. This list must include each access point that the device supports. The list entry for each access point client also contains a secret pass phrase the clients use to communicate with the RADIUS server. Enter a pass phrase for each access point, and then configure the keys for the corresponding APs so that they can be authenticated by the RADIUS server during EAPOL key processing. If the RADIUS server is also the authentication server, which is usually the case, this server must have two special user accounts: one for Transport Layer Security (TLS) Extensible Authentication Protocol (EAP) authentication, and one for the Protected Extensible Authentication Protocol (PEAP). The tests default to the following credentials for these accounts:
TLS authentication
User name: eaptls
Password: eaptls
Domain: wince
PEAP authentication
User name: eappeap
Password: eappeap
Domain: wince
The DHCP server provides a framework for passing configuration data to devices in a TCP/IP network, which eliminates the problems associated with manual configuration. When a DHCP server receives a request, the server automatically assigns an IP address from a pool of addresses, as well as assigning the address mask, the default gateway, the DNS server, the domain name, the WINS server (if used), and so on, to the device or computer that made the request.
The Wi-Fi Authentication tests run a variety of authentication and encryption methods to validate Wi-Fi functionality for a device, as shown in the table that follows.
General authentication methods
Authentication method |
Description |
|---|---|
Open |
All associations are accepted. |
Shared |
All associations are accepted, but the client must use WEP encryption. |
WPA |
Wi-Fi Protected Access. Requires EAP authentication. |
WPA-PSK |
WPA with a pre-shared key (PSK). |
WPA2 |
Wi-Fi Protected Access 2. Requires EAP authentication. |
WPA2-PSK |
WPA2 with PSK. |
EAP authentication methods
* Transport Layer Security (TLS)
* Message Digest 5 (MD5)
* Protected Extensible Authentication Protocol (PEAP)
Encryption methods
* Unencrypted (Clear Text)
* Wired Equivalent Privacy (WEP)
* Temporal Key Integrity Protocol (TKIP)
* Advanced Encryption Standard (AES)
For each combination of authentication and encryption protocols, the test performs the following steps:
1. Connects with an AP control server by using a fixed-configuration access point.
2. Requests the AP control server to configure an access point with a given authentication, encryption, and key.
3. Disconnects from the fixed-configuration access point.
4. Configures the device being tested to the so that it will connect to the access point that was configured in step 2 with the specified SSID, authentication method, encryption method, and key being tested.
5. Waits for a fixed interval for the connection to be established.
6. Sends a large number of ICMP pings through the newly-connected Wi-Fi link and checks for an equal number of replies.
7. Sends a large number of UDP echoes, and checks for lost or corrupted replies.
8. Sends a large number of TCP echoes, and checks for lost or corrupted.
9. Disconnects the wireless adapter.
The Wi-Fi Authentication Test is implemented as a Tux DLL. It can be started and configured remotely by using either CTK or Platform Builder , or locally by using a command script.
Test Prerequisites
Your device must meet the following requirements before you run this test.
Hardware Prerequisites
The following table shows the hardware requirements for the Wi-Fi Authentication Test.
Requirement |
Description |
|---|---|
Device under test |
The Windows Embedded Compact-based device or devices you want to test. |
Fixed access point (AP) |
This AP must not require 802.1X (EAP) authentication; that is, it must require Open, Shared, WPA-PSK or WPA2-PSK authentication. The device(s) under test use this AP to request AP test reconfiguration through the AP control server. |
One or more APs |
Every AP is controllable, and will be reconfigured during the testing by the AP control server. Each AP must be configured to communicate with the RADIUS authentication server. |
Control server for APs |
Processes AP configuration requests from the devices under test and updates APs to the required security mode. This server must also run the UDP and TCP Echo services so that the device(s) under test can verify wireless connections. |
RADIUS server |
Authentication server. You can run this service on its own computer, or on a computer that also runs the AP control server and the DHCP server. |
DHCP server |
Assigns IP addresses and processes client requests. You can run this server on its own computer, or on a computer that also runs the authentication and AP control servers. |
Local network |
Subnet to which the AP server, RADIUS server, and DHCP server all connect, so that the device can contact each server. |
Software Prerequisites
The following table shows the software requirements for the Wi-Fi Authentication Matrix Test.
Requirement |
Description |
|---|---|
Windows Server 2003, any of the Standard or Enterprise editions |
Basic server software requirement for running the Wi-Fi Authentication Test Suite. |
Tux.exe |
Test harness; required to run the tests. |
Kato.dll |
Logging engine, required to log data. |
Authmatrix.dll |
Test library. |
Apcontrol.exe |
Runs the AP control server. |
Enrolldll.dll |
Retrieves security certificate from the server that provides authentication services for the test network. |
Netall.dll |
Provides networking utilities; must reside on both the client and server. |
Subtests
This test has no subtests.
Setting Up the Test
The following table describes the steps that are necessary to create an appropriate test environment for running the Wi-Fi Authentication tests and, thus, validate the Wi-Fi functionality of the device.
To set up the test environment
1. Confirm that you carefully read the list of all the prerequisites and that all of the hardware and software requirements are met.
2. Set up the authorization servers on a computer that is running the Windows Server 2003 OS. For more information, see Authentication Server Setup located at <CTK installation path>\tests\target\%_TGTCPU%\wifimetric_ctk.docx.
3. Create a private network by connecting the access points and devices being tested to the computer that is hosting the servers.
4. Configure AP control server. For more information, see AP-Control Server Configuration located at <CTK installation path>\tests\target\%_TGTCPU%\wifimetric_ctk.docx. If you don’t have RF attenuator, you could set the registries to below:
[HKEY_CURRENT_USER\Software\Microsoft\CETest\APCTL\AP1]
"SSID"="DLinkAP"
"Configurator"="dlink;10.10.0.160:admin:admin"
"Attenuator"="Manual;0/-1/-1"
5. Configure Wi-Fi Authentication Access Points.
To run any of the Wi-Fi Authentication tests, you must configure the access points (APs) so that one is fixed, meaning that its configuration does not change and the AP Control server does not manage it. This AP acts as the static association point for devices connecting to the AP Control server.
To set up a fixed access point
This AP will be used to contact the AP-Control Server, the NDIS Performance server and so on. It must be available and configured as follows at all times. It does not have to be chosen from the Supported APs table.
1.Set the SSID for the fixed access point to WIFI_OPEN.
Important:
The authentication mode for the fixed access point must not require 802.1x (EAP) authentication, because at the beginning of the test, the device does not have all the certificates required to authenticate itself to the RADIUS server. You could set it to open authentication and disable encryption.
2.Give the access point a static IP address.
To set up a controllable access point
Four Access Points could be selected from this list. These APs will be re-configured throughout the test. These APs will also reside inside the RF-Enclosures and their RF signal strength will be controlled by the RF-Attenuator.
You must also configure one or more other access points that the AP Control server manages. Below Access Point types are currently supported by the AP-Control Server. D-Link DWL-3200 is recommended to be used for AP control server supports all the configuration of this AP.
Vendor/Model |
Firmware |
Supported Modes |
|---|---|---|
Cisco Aironet AIR-1232AG |
12.3(8)-JEA1 |
Open Shared WEP-802.1X WPA WPA-AES WPA-PSK WPA2 WPA2-PSK |
Cisco Aironet AIR-1240AG |
12.3(4)-JA or Later; LWAPP3.1 or later. |
Open Shared WEP-802.1X WPA WPA-AES WPA-PSK WPA2 WPA2-PSK |
D-Link DWL-3200 |
Version 2.10 or 2.20 |
Open Shared WEP-802.1X WPA WPA-AES WPA-PSK WPA2 WPA2-PSK |
1.Manually configure each controllable access point so it communicates properly with the RADIUS server:
1).Specify the server's IP address.
2).Specify the port through which the access points will communicate with the server, typically 1812.
3).Specify the shared key.
2.Configure each access point with a static IP address.
3.Connect to each of the access points from the AP Control server. To test each connection, retrieve the following initial information from each of the access points on the network:
◦SSID
◦IP Address
◦Administrator user name and password
Important: To ensure that all devices on your test network have valid and unique IP addresses, the test network must be isolated and private. Make sure that the test network is not connected to the corporate network.
Make sure that your private network is properly configured and that the static and dynamic IP addresses are properly assigned. Before you run any of the Wi-Fi Authentication Tests, you must verify that the complete RADIUS server test environment is properly established.
To validate the test environment
1.Reboot your server.
2.After your system is back online, make sure the computer that hosts the AP control server and RADIUS server has static IP addresses.
3.Make sure that the device that is being tested can connect to the fixed access point
4.Manually connect the device to the fixed AP and controllable AP. Verify that an IP address is dynamically assigned to the device.
After you have confirmed that your text network is set up correctly, you can begin running the Wi-Fi Authentication test.
Running the Test
The Wi-Fi Authentication Tests are implemented as a Tux DLL, named AuthMatrix.dll, and these tests comprise multiple test cases for seven different types of Wi-Fi authentication. .
Procedure
To run the Wi-Fi Authentication Tests
1. Verify that the test environment is set up correctly.
2. At a command prompt on the AP Control server, start the AP Control server by using command "apcontrol -debug".
3. Change eaptls.cfg file to set correct Server IP address, username and password;
4. At the command prompt on the device, enter "WiFiTool -disablecertinstall" to disable prompt when installing certificate.
5. At the command prompt on the device, enter the Tux command with the options required for the test you want to run.
The Wi-Fi Authentication Tests run from the command line. The combination of authentication and encryption in each test depend on the command-line parameters you include when you start the test. To simplify the description of the parameters, this topic describes one of the parameters and links to other topics that describe the rest of the parameters.
Syntax
tux.exe [tuxparams] -d authmatrix.dll [-c "[-adapter adapterName] [apParameters] [enrollmentParameters] [logonParameters] [miscParameters]"]
Command-Line Parameters
-d authmatrix.dll
Specifies the DLL to use for the Wi-Fi Authentication Tests.
-c " … "
Specifies a list of test-specific parameters that Tux passes to the test DLL. -c "-?" will print out all the parameters usage.
-adapter adapterName
Specifies the name of the wireless adapter to use in the test. If you omit this parameter, the test uses the first wireless adapter it finds.
apParameters
Specifies the AP Control Server by hostname and port.
Command-Line Parameter |
Description |
|---|---|
-wHost |
WiFi server name/address (default "10.10.0.1") |
-wPort |
WiFi server port (default 33331) |
-wSSID |
WiFi server SSID (default "") |
-wAuth |
WiFi server authentication (default "Open") |
-wEncr |
WiFi server encryption-cipher (default "ClearText") |
-wEap |
WiFi server EAP auth-mode (default "TLS") |
-wIndex |
WiFi server WEP-key index (default 0) |
-wKey |
WiFi server encryption-key (default "") |
enrollmentParameters
Specifies how the AP Control application, APControl.exe, reaches the authentication server, and how to run the certificate enrollment program. The following table shows the certificate enrollment command line parameters for the Wi-Fi Authentication Matrix Test.
If the EAP tests are enabled, the first test automatically retrieves certificates for authenticating EAP connections. The certificate enrollment settings tell the test application how to reach the authentication server and how to run the certificate enrollment program.
Command-Line Parameter |
Description |
|---|---|
-nHosthostName |
Specifies the enrollment host name or address. The default value of hostName is 10.10.0.1. |
-nCommandcmd |
Specifies the enrollment host command name. The default value of cmd is enroll. |
-nRootBoxtitle |
Specifies the title of the set root cert dialog box. The default value of title is Root Certificate Store. |
-nToolBoxtitle |
Specifies the title of the "insert new cert" dialog box. The default value of title is Enrollment Tool. |
-nWaitTimetime |
Specifies the time in milliseconds to wait for command. The default value of time is 900000, which equals 15 minutes. |
logonParameters
Each time a Wi-Fi Authentication test connects using WEP 802.1X, WPA or WPA2, the test must authenticate with the RADIUS server. The user logon settings specify how the application should interact with the user-credentials dialogs on the device. You rarely need to specify these test parameters because the test application usually provides the credentials directly, so the dialogs are not normally used, and the defaults are usually appropriate.
Command-Line Parameter |
Description |
|---|---|
-uUsrBoxname |
Specifies the title of the user logon dialog box. The default value is User Logon. |
-uNetBoxtitle |
Specifies the title of the network password dialog box. The default value of title is Enter Network Password. |
-uWaitTimetime |
Specifies the time in milliseconds to wait for the dialog to close. The default value of time is 300000, which equals five minutes. |
miscParameters
Specifies segments of the tests to skip, APs to use, logon credentials, and test iterations and timeouts.
Command-Line Parameter |
Description |
|---|---|
-dOpen |
Disables (skips) Open System (no authentication) tests |
-dShared |
Disables Shared (WEP authentication) tests |
-d802 |
Disables 802.1X (dynamic WEP) tests |
-dEAP |
Disables EAP (RADIUS) tests (WEP 802.1X, WPA and WPA2) |
-dPSK |
Disables PSK tests (WPA-PSK and WPA2-PSK) |
-dWPA2 |
Disables WPA2 tests (AES, WPA2 and WPA2-PSK) |
-dClear |
Disables ClearText (no encryption) tests |
-dWEP |
Disables WEP encryption tests |
-dTKIP |
Disables TKIP encryption tests |
-dAES |
Disables AES encryption tests |
-dPEAP |
Disables PEAP EAP-authentication tests |
-dTLS |
Disables TLS EAP-authentication tests |
-tAPNamesname1,name2,... |
Specifies a comma-separated list of access point (AP) names. Normally, the test selects from among all the APs controlled by the AP control server. The -tAPNames parameter forces the application to select from the listed APs. If the list contains multiple AP names, the tests applies the following rules to choose the AP: 1.If an AP has a matching security mode, use it. 2.Else, if not all the APs support the security modes, use the first that does support the mode. 3.Else, use the first AP in the list. |
-lTLStlsCred |
Specifies the TLS login credentials in the format user_name:password:domain_name. The default value of tlsCred is eaptls:eaptls:wince. |
-lPEAPpeapCred |
Specifies the PEAP login credentials in the format user_name:password:domain_name. The default value of peapCred is eappeap:eappeap:wince. |
-tPassesnum |
Specifies the number of times to repeat each connection. The default value of num is 1. |
-tConnTimetime |
Specifies the time in seconds to await a connection. The default value of time is 140. |
Example:
s tux -o -d authmatrix.dll -c"-adapter PCI\RTLNWIFI1 -wHost 10.10.0.1 -wPort 33331 -wSSID WIFI_OPEN -lPEAPeaptls:password:wince -lPEAPeappeap:password:wince"
Verifying the Test
When the test completes running, verify that "PASS" appears in the test log for all subtests
Troubleshooting the Test
Test cases 2200, 2300, 3000, 3200, 3300, 5000, 5100, 6000, 6100, 6220, 6250, 6320, 6350, 7000, 7100, 8000, 8100, 8220, 8250, 8320, and 8350 are expected to fail, because they intentionally provide incorrect information to make sure that the authentication fails when it should. Since these failures are normal, the test cases will return a PASSED value when the invalid association attempts fail.