One-Card Network Card Miniport Driver Test (Compact 7)
3/12/2014
The One-Card Network Card Miniport Driver Test assesses the functionality of a miniport driver for a single network card. You can also use this test to verify that the driver supports Network Driver Interface Specification (NDIS) functionality.
This test is comprised of two binaries, Ndt.dll and Ndt_1c.dll. The Ndt.dll binary file is a protocol driver that binds to the test and support cards. The protocol driver communicates with the underlying miniport drivers through an NDIS wrapper and registers as a stream driver. The Ndt_1c.dll binary file controls the test itself.
Test Prerequisites
Your device must meet the following requirements before you run this test.
The following table shows the hardware requirements for the One-Card Network Card Miniport Driver Test.
| Requirement | Description |
|---|---|
Network interface card |
The network card to be tested should be connected to an isolated test network with no other network traffic. |
Second network interface card |
The target device should also have a second network card that establishes a TCP/IP connection to the development workstation. When developing Windows Embedded Compact target devices, the development workstation must be running 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 it to the test network. The second network card on the development workstation is not required to run the One-Card Network Card Miniport Driver Test but can assist in troubleshooting problems that may arise.
The following table shows the software requirements for the One-Card Network Card Miniport Driver Test.
| Requirements | Description |
|---|---|
Tux.exe |
Test harness, required for executing the test |
Kato.dll |
Logging engine, required for logging test results |
Ndt.dll |
Protocol driver for the test |
Ndt_1c.dll |
Tux test binary file |
The miniport driver being tested should be recognized by NDIS. You should assign a name to the network card in order for the test to function correctly.
Note:
When you run the One-Card Network Card Miniport Driver Test, the Windows Embedded Compact Test Kit (CTK) temporarily copies files to the root directory of the target 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 target device. Also verify that there is at least 1.0 MB of free program memory on the target 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 |
Open\Close Tests the ability to open and close an adapter multiple times. A miniport driver is shielded from the opening of an adapter by the Ndt.dll protocol driver. As a result, this test case tests the Ndt.dll protocol driver rather than the miniport driver. This test case opens and closes one instance of NdisOpen 16 times, and then opens and closes 128 concurrent instances of NdisOpen 16 times. This test fails if the miniport driver has a problem with multiple open instances of NdisOpen. |
2 |
Send Tests the ability to send data both singularly and in bursts. The test case attempts to send data to the various address types supported by the media type of the current driver. This test case fails if a problem occurs with sending packets. |
3 |
Loopback send Tests for the ability to receive loopback packets with a variety of address types on multiple filter settings. The test uses one open instance to send loopback packets and eight instances to receive the packets. Each of the eight instances receiving the packets has a different filter setting, which allows for all supported filter settings to be tested quickly. This test case also verifies that no open instance receives a packet that it should not be receiving. This test case fails if a problem occurs with a filter setting in a driver. |
4 |
Loopback stress Creates packets with various buffer configurations in order to perform 10 instances of the stress test on the loopback packets. This test case fails if a memory leak is detected. |
5 |
Set multicast Tests the ability of the Ethernet and Fiber Distributed Data Interface (FDDI) drivers to create multiple multicast addresses. The test does not verify that the card is able to receive on each of the different addresses. The test verifies only that multicast addresses can be set and deleted. |
6 |
Reset Attempts to reset the network card multiple times while simultaneously sending large numbers of packets. The test also verifies that the card can reset itself in order to properly handle packets that are ready to send when interrupted by a reset. This test case fails if the operation that resets the network card is implemented incorrectly. |
7 |
Cancel send Runs the performance command with a flag that causes the Ndt.dll protocol driver to cancel packets. The performance command queues 100 packets to send. In the next packet to send, the performance command sets the cancel identification, and then attempts to cancel the send operation. This test case fails if an improper cancellation of a packet occurs. |
8 |
Fault handling Sets bits in the registry for the network card driver using the fault injection NDIS technology. These bits cause NDIS to fail the NdisMAllocateMapRegisters, NdisMRegisterInterrupt, NdisMAllocateSharedMemory, NdisMMapIoSpace, NdisMRegisterIoPortRange, ReadNdisGetSetBusConfigSpace, WriteNdisGetSetBusConfigSpace, and NdisMInitializeScatterGatherDma functions. The driver should not load correctly unless it does not call a particular function. |
9 |
Object identifiers Performs a series of NdisRequest function calls to the driver. Verifies that the driver supports the querying of all required object identifiers. |
10 |
64 bit object identifiers Tests the OID_GEN_XMIT_OK and OID_GEN_RCV_OK object identifiers to verify that all queries are handled properly. Each object identifier is queried three times. The object identifier is queried once with a null buffer, once with a 4-byte buffer and once with an 8-byte buffer. |
11 |
Suspend and then resume Tests the behavior of the network card driver when the test suspends and then resumes the operating system (OS). If the run-time image does not support the IOCTL_HAL_ENABLE_WAKE IOCTL or does not wake in response to a SYSINTR_RTC_ALARM interrupt, this test case is skipped. This test case suspends and then resumes the OS 5 times and then attempts to send data over the network card driver to verify that the driver is functional. |
12 |
Stress suspend and then resume Tests power management of the network card driver and stresses the network card driver under suspend and resume operations. This test case has three threads. The main thread performs suspend and resume operations. The second thread sends data continuously over the network card driver. The third thread queries object identifiers (OIDs) continuously. If the network card driver supports power management, the main thread requests that Device Manager put the network card into a D4 state. After one second, the main thread requests that Device Manager restore the network card to a D0 state. If the network card driver does not support power management, the main thread performs a reset operation on the network card and then waits for a random interval of time. This test case assesses the ability of the network card driver to process send requests and OID requests while undergoing power transition. This test case performs 25 suspend and then resume operations. |
13 |
Reset on resume Tests the ability of the network card driver to restore its original settings when a resume operation resets the network card driver. This test case first sets a packet filter, multicast list size, and look-ahead buffer size. This test case then adds multicast addresses to the multicast list. After a reset operation, this test case verifies that the network card driver preserves its original settings. |
Setting Up the Test
You must update the default command line for this test prior to running the One-Card Network Card Miniport Driver Test.
Replace the [TestCard] part of the command line with the name of your miniport adapter as reported by ndisconfig ("s ndisconfig -d" from the Platform Builder's "Windows CE>"). The Command Prompt window will show the names of miniport adapters in the system.
Running the Test
You must modify the test by further editing the command line. The following table shows the command line parameters for the One-Card Network Card Miniport Driver Test.
| Command line parameter | Description |
|---|---|
-t <adapter> |
Target network adapter to test |
-packets |
Logs information when a test confirms that a packet has been sent or received. |
-nounbind |
Disables unbinding of other protocol drivers from the test adapter before the test is run. |
-fault |
Includes test case 8, which is skipped by default. Only ISA and PCI network cards support test case 8. |
-cancel |
Instructs test case 7 to fail when no packets are canceled. By default, test case 7 does not fail when no packets are canceled. |
The following procedure shows how to configure the target device and development workstation, after you have built a run-time image with support for the network card that you want to test.
To run the One-Card Network Card Miniport Driver Test
1. Boot the target device, and then verify that the network card is operational.
2. On the development workstation, open the Windows Embedded Compact Test Kit (CTK) window. After the target device connects, find the NDIS Test entry in the CTK window and edit the associated command line by specifying the device name of the network interface.
For example, for a PCI NE2000 card, type -c "-t PCI\NE20001" at the end of the command line. The entire command line reads tux -o -d ndt_1c -c "-t PCI\NE20001".
Note:
To determine the device name of the network interface, run the test without parameters. The log file generated by the test shows the device names of all network interfaces recognized by the system. Do not run this test on the Vmini network interface.
3. Start tests for the target device:
Verifying the Test
When the test completes running, verify that "PASS" appears in the test log for all subtests.
Troubleshooting the Test
* Ensure that the Windows Embedded Compact-based device is connected to an isolated network with no other network traffic.
* Ensure the test adapter name is correct.
For additional platform specific issues, consult the CTK articles on the TechNet wiki.