Troubleshooting Wireless LAN (802.11) Tests
This topic describes some common troubleshooting tips for WLAN testing. To begin:
Review the Windows HCK release notes for current test issues.
For a test failure, look for usable information in the Windows HCK Studio test log. If you find usable information, resolve the issue and rerun the test.
Changes that you made to devices on HCK clients machines are not reflected in HCK Studio. For example, the machine is expected to be in the Ready state but it is not.
Open a Command Prompt window on the client machine, and then run net stop wttsvc.
Run net start wttsvc. This command will update the C:\wtt\JobsWorkingDir\AssetCfg\Log\ directory.
Restart the HCK Studio. You might have to wait several minutes for the HCK controller to poll the client machine for changes in its device list.
Machines have not been discovered for the machine pool.
Open the Job Monitor window in HCK Manager.
Select the Show Query Builder button at the top of the screen.
Click the Machine Query tab.
Define search parameters for the machines that you are looking for. Typically, you can set a single rule such as "DataStore equals 'Controller Name'".
Right-click the rule that you just defined, and then click Execute. An extensive list of machines should populate the Machines list below the query fields that you defined.
Drag any machines in the Machines list into new machine pools that you created.
Machines do not seem to run jobs that are scheduled for them.
Check the names of the NICs on the DUT, SUT and AP machines. They must be MessageDevice for the Ethernet and SupportDevice0 and SupportDevice1 for the WLAN NICs. If not rename them manually.
Make sure that for each machine in the pool, status is Ready.
Open the Job Monitor window in HCK Manager.
In the Machine Pool tab, select the machine pool that you expect to be running jobs.
If a machine's status is not Ready, right-click the machine, point to Change Status, and then click Reset.
After a few minutes, refresh the screen and the status will change to Ready.
Schedule and start the jobs again.
Problems with installing the Test SoftAP driver on the topology: Device Manager reports code 52
Do not install the x64 Test SoftAP driver before installing the HCK client. When the HCK client is installed, the Root Certificate is installed. Because the Test SoftAP driver signing depends on installation of the Root Certificate, the device manager reports device code 52.
Configuring NDISTest for stand-alone execution
Installing NDISTest separate from HCK Studio enables you to execute individual tests. A DUT, SUT, and Test SoftAP need to be configured to enable stand-alone execution.
Note
All test machines must use the same processor architecture.
Note
To troubleshoot the NDISTest, try attaching a debugger to the test machine.
Configuring a Support Device Under Test (SUT)
Copy all NDISTest binaries and sub directories from the following HCK controller:
\\<ControllerName>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\<ControllerName> is the name of the HCK controller computer and <architecture> is either x86 (for x86-based processors) or amd64 (for x64-based processors).
Launch NDISTest.exe from the install directory. When the main form opens, select Server from the File menu to launch the server form.
Select the message device from the Message Device list. This device must be IP-enabled and on the same subnet as the client message device that will be set up later.
Select SUT device(s) from Support Devices. The support device selected on this server from will be visible to the client after the server is started.
Select the "server" job from Jobs. This is the server side test that will be launched after you click the start button.
After all the options have been selected, click Start to start the server.
Configuring a Test Software Access Point (Test SoftAP)
Copy all NDISTest binaries and sub directories from the following HCK controller:
\\<ControllerName>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\
<ControllerName> is the name of the HCK controller computer and <architecture> is either x86 (for x86-based processors) or amd64 (for x64-based processors).
Install SoftAP driver for both of the Atheros WLAN devices on the Test SoftAP. You can install this driver from Device Manager, which you can open by running devmgmt.msc from a command prompt. Complete the following step:
In Device Manager, install the driver for SoftAP stations from \\<ControllerName>\Tests\<architecture>\nttest\nettest\ndis\NDISTest.net\SoftAPMiniport\
<ControllerName> is the name of the HCK controller computer and <architecture> is either x86 (for x86-based processors) or amd64 (for x64-based processors), depending on the processor architecture of the HCK client machine that have the SoftAP devices.
Launch NDISTest.exe from the install directory. When the main form opens, select Server from the File menu to launch the server form.
Select the message device from the Message Device list. This device must be IP-enabled device and on the same subnet as the client message device that will be set up later.
Select the AP device(s) from AP Devices. AP devices selected on this server will be visible to the client after the server is started.
Select the "server" job from Jobs. This is the server side test that will be launched after you click the start button.
After all the options have been selected, click Start to start the server.
Configuring the Device Under Test (DUT)
Copy all NDISTest binaries and sub directories from the following HCK controller:
\\<ControllerName>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\
<ControllerName> is the name of the HCK controller computer and <architecture> is either x86 (for x86-based processors) or amd64 (for x64-based processors).
Launch NDISTest.exe from the install directory. When the main form opens, select Client from the File menu to launch the client form.
Select the test target from the Test Target list. For network device, this test target should be Miniport.
Select the test device from the Test Device list. This must be a vendor-specific test device.
Select a message device from the Message Device list. This should be an IP-enabled device that is on the same subnet as the server message device. After the message device has been selected, the AP device section should be displayed and the server AP device should be available in the list.
Select a support device from Support Devices. This must be a vendor-specific support device.
Select an AP device from AP Devices. This must be the AP device that was select on the server side.
Select the tests from the Jobs section that will be run after the client is launched.
After all the options have been selected, click Start to start the client. Any jobs that were selected will begin execution. Test results will be stored on the client in the following logging sub-folder:
<NDISTestRootFolder>/logs/<AdapterName>/
Configuring Client Packet Capture
Configure a test topology for stand-alone execution. For more information, go to "Configuring NDISTest for stand-alone execution."
Setup a second SUT. For more information, go to "Configuring a Support Device Under Test (SUT)."
Launch NDISTest.exe from the install directory. When the main form opens, select Debug from the View menu to launch the Packet Capture section on the client.
Select a Capture device from Packet Capture. This must be a Support device that was selected on the server side.
From Jobs, select the tests that will be run after the client is launched.
After all of the options have been selected, click Start to start the client.
Packet captures corresponding to the Tests will be generated on the Server with the capture device. The logs will be in the following logging sub-folder:
<NDISTestRootFolder>/logs/<AdapterName>/
Troubleshooting when the Packet Capture section does not show up on client
Verify that the message center user interface is closed. If the NDISTest user interface is not maximized, the Packet Capture section may be hidden behind the message center user interface.
I want to open a bug. What should I include in the bug:
Create a .hckx package containing the failed tests – see the “Creating a Package” section and attach it to the bug.
Failing Logs –Please gather the ndistest logs from the test run and include them with the package in the bug. The logs can be found by doing the following:
Open the HCK Manager
Choose Explorers> Job Monitor
Choose the Machine Pool that you scheduled the tests on.
In the right pane choose the DUT machine.
Under Job Execution Status right click the Job name of the test you ran and select Browse Job logs.
This will open up an explorer window with an AP, Server, and Test directories. Zip these directories and attach them to the bug.
How do I reset my machines after a failed run?
Below is a chart with common problems and solutions.
Symptom |
Solution |
The VAN UI doesn’t show any networks |
1 |
When I connect my WLAN device to a DHCP enabled network I don’t get an IP. |
2 |
I get strange "Back Channel" failures |
2 |
The (SUT, DUT, or AP) machine crashed and now all tests are failing |
1,2,3 |
NDISTest isn’t auto finding my test adapter when running through the HCK |
3 |
The HCK test is failing to populate either a MessageDevice or SupportDevice |
3 |
I updated my HCK Controller and not my clients and now I am seeing strange crashes and failures that I have never seen before |
When moving to a new controller you should also rebuild your clients. In the event that is not feasible you will need to remove ndprot630.sys from all three machines and athr.sys and softap.sys from the AP machine. All these files are in the c:\windows\system32\drivers directory. Ndprot630.sys will be automatically re-loaded when NDISTest is run, but not overwritten. ather.sys and Sofap.sys will need to be copied over from the new controller. |
My physical AP's don’t seem to be working like before |
You may have to reset/reboot your physical ap. If you factory reset it make sure you set the channel and radio per the setup instructions. |
I have tried all the steps above but nothing worked |
If you have tried the above steps and are still seeing issues you can uninstall then reinstall the WLAN adapter. Make sure when you are done to rename the adapter SupportDevice0. |
Related topics