Wi-Fi Authentication Tests (Compact 7)

3/12/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

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.

Software Prerequisites

The following table shows the software requirements for the Wi-Fi Authentication Matrix Test.

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.

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.

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.

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.

miscParameters

Specifies segments of the tests to skip, APs to use, logon credentials, and test iterations and timeouts.

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.

For additional platform specific issues, consult the CTK articles on the TechNet wiki.

See Also

Other Resources

Networking - Bluetooth, Modem, Wireless Tests