Two-Card Network Card Miniport Driver Test (Compact 7)
3/12/2014
The Two-Card Network Card Miniport Driver Test assesses the functionality of a miniport driver on a target device with two network cards. The network cards used in the test must be recognized by the Network Driver Interface Specification (NDIS) architecture.
The tests will perform basic send/receive packet tests along with more complicated multicast and stress-related scenarios.
Test Prerequisites
Your device must meet the following requirements before you run this test.
The following table shows the hardware requirements for the Two-Card Network Card Miniport Driver Test.
| Requirement | Description |
|---|---|
Network card |
Your Windows Embedded Compact-based device must have an installed network card for which the miniport driver is to be tested. Note: Do not use the Vmini network interface with this test. Running the test over the Vmini interface disables the KITL connection between the development workstation and the Windows Embedded Compact-based device. |
Second network card |
The device must have a second installed network card that functions as a support card. The support card can be identical to the test card. You should connect the test and support cards to an isolated test network with no other network traffic. |
Third network card |
The device should also have a third network card that establishes a TCP/IP connection to the development workstation with Platform Builder for Windows Embedded Compact 7. |
If you want to monitor traffic on the test network with network monitoring software, you can install a second network card on the development workstation and then connect the second card to the test network. The second network card on the development workstation is not required to run the Two-Card Network Card Miniport Driver Test but can assist in troubleshooting problems that may arise.
The following tables show the software requirements for the Two-Card Network Card Miniport Driver Test.
| Requirement | Description |
|---|---|
Tux.exe |
Test harness, required for executing the test |
Kato.dll |
Logging engine, required for logging test results |
Ndt.dll |
Test protocol driver |
Ndt_2c.dll |
Tux test binary file |
The network cards that you use must be recognized by the Network Driver Interface Specification (NDIS) architecture. You must assign a name to each network card prior to running the test. The run-time image that you download to the device must use shared miniport drivers on control cards. You must bind the TCP/IP protocol to one of the miniport drivers.
Note:When you run the Two-Card Network Card Miniport Driver Test, the Windows Embedded Compact Test Kit (CTK) temporarily copies files to the root directory of the device. While the test runs, the test dynamically consumes program memory on the device. Before running the test, verify that there is at least 0.4 megabytes (MB) of free storage memory on the device. Also verify that there is at least 1.0 MB of free program memory on the device. If there is not sufficient space in the root directory of the device or there is not sufficient program memory, the test cannot run.
Subtests
The table below lists the subtests included in this test.
| SubTest ID | Description |
|---|---|
1 |
Send packets Sends packets using the NdisSendPackets function. The test uses various burst and packet sizes and logs a failure if any problems occur during NdisSendPackets. This test case uses either a minimum packet size of 64/96 bytes, the maximum packet size supported by the medium, or an average of these two sizes. |
2 |
Receive packets Tests whether the card is able to correctly receive packets on its hardware Media Access Control (MAC) address. |
3 |
Filter receive Tests whether the card is able to correctly receive packets with various addressing types. The test uses one open instance to send and eight instances to receive. Each of the eight receiving instances has a different filter setting, which allows all supported filter settings to be tested quickly and verifies that an open instance does not receive a packet that it should not receive. |
4 |
Multicast receive Tests whether the card is able to receive on as many different multicast addresses as the card claims to support. The test uses all available multicast addresses and attempts to send packets to each of those addresses. The test also verifies that packets are only received on the multicast addresses that are active. |
5 |
Stress send Executes a stress test between the test card and the support card on the device. The test card sends packets and the support card receives packets. The test runs for 10 iterations with various buffering options. The test also verifies that the test card can send packets of differing size at a faster rate and can simultaneously receive different types of acknowledgement packets. Packet loss may occur in this test. |
6 |
Stress receive Executes a stress test between the test card and the support card on the device. The support card sends packets and the test card receives packets. The test runs for five iterations with various buffering options. The test also verifies that the test card can receive packets of differing size at a faster rate and can simultaneously send different types of acknowledgement packets. Packet loss is common during this test. The main criterion for success is that the miniport driver should be able to handle send and receive requests with various buffer configurations. |
Setting Up the Test
The following shows how each configuration can be setup.
Configuration 1:
1. Boot the device, and then verify that the network cards are operational.
2. Connect to the device via the Test Kit.
3. Replace the [TestCard] and [SupportCard] parts of the command line with the name of your miniport adapters as reported by ndisconfig.exe ("s ndisconfig -d" from the Platform Builder Command Prompt will show you the names of miniport adapters in the system)
The test and support cards should be connected to an isolated network with no other network traffic. The test can run on a network segment with traffic but the test is likely to interfere with other network traffic.
Configuration 2 or 3:
You can run the two-card test in a scenario that includes two devices. This is done when the test device has only one ethernet card and more cannot be added. In such a scenario, each device has one network card for testing, each connected to the same isolated network. Some form of KITL connection must also exist so that you can connect to the Test Kit and give commands via Platform Builder. This KITL connection can either be through a second ethernet card on each device or another medium such as USB.
1. Boot the device, and then verify that the network card is operational. (ipconfig)
2. Connect to the device via the Test Kit.
3. Boot the support device(connected to another Platform Builder instance), and then verify that the network card is operational. (ipconfig.exe)
4. On the support device: start ndtserver.exe. ("s ndtserver" via Platform Builder) . Note the ip address of the support device's ethernet adapter <IP address>. Modify the test's command line so that instead of "-s [SupporttCard]" you have "-s [SupportCard]@<ip address>".
Example:
Lets say you have 2 devices each with one network card, apart from KITL. You boot up images on both devices via Platform Builder. The test device has an e100bex card which comes up as "PCI\E100BEX1".
Let the support device have an RTL8139 card that comes up as "PCI\RTL81391". Let the IP address of this card be 169.254.47.27 when connected to the isolated hub that the e100bex is connected to.
First you would start ndtserver6 on the support device via its Platform Builder connection: s ndtserver6
Once the server starts, your command line on the test device would be:
Running the Test
The Two-Card Network Card Miniport Driver Test executes the default command line. You can modify the test by editing the command line. The following table shows the command line parameters for the Two-Card Network Card Miniport Driver Test.
| Command line parameter | Description |
|---|---|
-s <adapter> |
Support network adapter |
-t <adapter> |
Target network adapter to test |
-nounbind |
Disable unbinding of other protocol drivers from the test adapter before the test is run. |
-nostress |
Skip test cases 5 and 6. |
-wait secs |
Timeout in seconds for NDTSendWait() calls |
-forcetestnicwifi |
Make the test adapter appear to be wireless, even if NDIS detects it to be wired |
To run the Two-Card Network Card Miniport Driver Test
1. Boot the device, and then verify that the network cards are operational.
2. On the development workstation, open the Windows Embedded Compact Test Kit (CTK) window. After the device connects, find the Two-Card Network Card Miniport Driver Test entry in the CTK Test Pass window and edit the associated command line by specifying the device names of the network interfaces.
Note:
To determine the device names of the network interfaces, run the test without parameters. The log file generated by the test shows the device names of all network interfaces recognized by the system.
3. Start tests for the device.
You can run the two-card test in a scenario that includes two devices. In such a scenario, each device has one network card for testing and one network card for support. The network cards for testing are connected to an isolated test network.
After setting up the hardware, In the CTK window on the development workstation, edit the command line for the Two-Card Network Card Miniport Driver Test entry. Specify the name of the network card for support in the form Card_name@IP_address.
Verifying the Test
When the test completes running, verify that "PASS" appears in the test log for all sub-tests.
Troubleshooting the Test
Test failures and what they may mean for your miniport driver:
Test 1: Your miniport is having trouble sending packets, even in non-stress conditions.
Test 2: Your miniport is having trouble receiving packets, even in non-stress conditions.
Test 3: Your miniport is not settting up receive filters correctly. Check your OID_GEN_CURRENT_PACKET_FILTER handlers in the miniport code.
Test 4: Your miniport is having trouble handline multicast addresses. Check your OID_802_3_MULTICAST_LIST, OID_802_3_MAXIMUM_LIST_SIZE handlers in your miniport code.
Test 5 and 6: Your miniport has trouble handling simultaneous send and receive of many packets.
For additional platform specific issues, consult the CTK articles on the TechNet wiki.