LAN (Ethernet) Testing Overview
Note This content applies to the Windows Logo Kit (WLK). For the latest information using the new Windows Hardware Certification Kit (HCK), see Windows HCK User's Guide on the Windows Hardware Dev Center.
The procedures that are presented in this section outline the process for testing your LAN device for correct functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that DTM identifies as required for the device.
Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.
Note Windows Server 2008 R2 is supported.
The test procedures in this section are divided into the following types of topics:
Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.
Running: The running topics describe how to run the tests for your device or system.
Troubleshooting / Frequently Asked Questions: The troubleshooting topics describe how to diagnose and fix common problems encountered while you test LAN (Ethernet) devices.
The tests that you must run depend on the capabilities of the device or system that you are testing. The DTM determines which tests are applicable for your device based on the information collected for your device by DTM. To see the complete list of tests that you might need for your device, see LAN Device Tests.
Run time: approximately 12 hours
Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device. Additionally, run Storage > Adapter and LAN (Ethernet) test submissions for Windows Server 2008 on systems with a minimum of 4 processor cores and 6 gigabytes of memory. These requirements are in addition to those related to the Dynamic Partitioning (DP) Simulator and Test that all Windows Server 2008 device driver submissions must meet.
If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.
For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.
Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.
On a conceptual level, in order to test a LAN (Ethernet) networking card, two computers must be used. One computer is needed to hold the device under test and another computer and network device is needed to receive and send data to the device under test while testing is in progress. Additionally, there must be a separate line of communication between the two computers that will be used to exchange information about ongoing tests. For example, on a send test it is beneficial for the receiver of the data to know how much traffic to expect from the sender.
A DTM setup for LAN (Ethernet) device testing consists of a DTM controller, DTM Studio, and DTM clients.
The following figure shows the relationship between these computers.
Note DTM Studio and the DTM controller can be running on one computer to reduce the cost of the setup.
Here is a summary of each computer in the figure, devices installed in them, and the computer role during testing:
DTM Studio computer - Used to manage all the DTM client computers during testing. See DTM Studio
DTM Controller computer - Used to control DTM client computers and gather all test information from them. See DTM Controller.
- DTM Client 1 computer - This computer, during the LAN device testing, is referred to as the remote test machine, or NDISTest server. This computer contains the following network devices:
- Remote support device - A device that communicates with the DTM controller. This device also communicates the test status information to the local support device in the local test machine via the support network.
- Remote message device - A device that communicates with the local test device in the local test machine via the test network.
- DTM Client 2 computer - This computer, during the LAN device testing, is referred to as the local test machine, or NDISTest client. This computer contains the following network devices:
- Local test device - This is the device under test. During testing it communicates to the remote message device in the remote test machine via the test network.
- Local message device - This device communicates with the DTM controller. It also communicates test status information to the remote support device in the remote test machine via the support network.
- Other local devices - "NDISTest 6.5 (PM and WoL)" job requires any local device other than local test device and local support device to be disconnected from the network.
You can use DTM Studio to schedule the LAN device test job on the DTM clients that are registered on the DTM controller. The following steps summarize the scheduling procedure:
Enter all of the information that the LAN device test job needs into DTM Studio, and schedule the job.
The LAN device test job requires two DTM client machines. For logo submission, you will also need three identical network cards. These requirements are enforced when you configure the DTM job.
DTM Studio sends job configuration information to the DTM controller, which reserves the DTM clients and dispatches the job to them.
The DTM clients run the job. They first copy NDISTest, which is the actual LAN device test tool, to the DTM clients and run NDISTest on the desktop of the user that is currently logged in.
After the test is finished, the log files are gathered and copied on the DTM controller.
The NDISTest 6.0 "2c_priority" script has been removed and separated into its own job to enable running the NDISTest 6.0 with a crossover cable between the test and support adapter. This change is to address the difficulty some vendors experienced with the switch stripping the priority header. The new job is named "NDISTest 6.0 (Priority)"
- The NDISTest 6.5 "LinkCheck", "PowerManagement", "WoLMagicPacket", and "WoLPattern" scripts have been removed and separated into their own jobs.
- The "NDISTest 6.5 (Manual)" job now runs only the "LinkCheck" test. This is the only manual LAN script. This change is to ease the tester's job of pulling the cable by providing discreet scheduling.
- The "NDISTest 6.5 (PM and WoL)" job now runs the Power Management and Wake-on-LAN tests (PowerManagement, WoLMagicPacket, and WoLPattern). This change is to enable running the test on a machine that more readily supports power management and Wake-on-LAN. The machine does not need to be a multiprocessor machine.
- Two new jobs have been added to NDISTest 6.5.
- The "NDISTest 6.5 (Premium)" job tests to verify the support of six Wake-on-LAN patterns.
- The "NDISTest 6.5 (MPE)" job is a new testing methodology (Multi-path Exerciser) that repeatedly schedules multiple tasks in parallel looking for severe driver failures. The tasks perform activities such as sending and receiving packets, resetting the driver, manage power on the host machine, query OIDs, pause and restart the driver, and halt and initialize the driver. Some of these problems can be difficult to diagnose and MPE has proven to be an effective test at diagnosing them.
Build date: 9/14/2012