NDISTESTER Version 3.77

INSTALLATION

The Network Device Tests consist of a user interface, the Ndis Tester, and the Tdi Tester.  The entire test suite is usually call the NdisTester.  The test suite can be installed from ftp.microsoft.com/services/whql/ndis, the WHQL web site, or from the HCT CDROM. It is recommended that you install from the ftp site or WHQL web site. The ftp site should always contain the most recent version of the tester. The WHQL web site contains the version currently being used by WHQL for certification tests.

If you are downloading from the ftp site, you need to unzip the downloaded file to produce the installation source tree. The best way to do this is to first create a subdirectory, then download the self-extracting archive file to that subdirectory. Then extract the files from that archive using the '-d' option. For example, if the file name was ndisbeta.exe, then use 'ndisbeta -d' to extract it. If you don't use this option, then you will not get all the files, and the ones you do get will not be in the locations that ndsetup.bat expects. 

To install the tests, run "ndsetup <dest>", where dest is the destination directory for the tester. For example, if you want to install to d:\ndistest, then the complete command would be "ndsetup d:\ndistest".

Unless you absolutely need to have multiple versions of the tester on your machine, it is best to have only one version on all your machines. If you encounter any problems when installing the tester, you should try manually deleting the old installation directory. Then for NT4 and Windows2000, use regedt32 to delete the key NdisTest under HKLM\System\CurrentControlSet\Services. For Win98, make sure that the NdisTest is NOT listed as a protocol under network configuration. (If it is, remove it!).

If you are not running with administrative privileges, then the installation may give a failure message when running setupreg.exe. If this happens, you should switch to a logon with administrative privileges and re-run setupreg.exe. (This program sets up some things in the registry so the ndis tester can check for possible memory leaks).

You SHOULD set up a debugger before starting to run the ndis tester. The tester can send quite a lot of messages to the debugger that will greatly aid you in tracking down problems. Also, there are several breakpoints in the tester that can be hit--especially if any data corruption is detected. Having a debugger connected will allow you to determine if the tests are just "hanging", or if some situation has been detected which resulting in a breakpoint being hit.

For NT4 and Windows2000, you need to copy the symbols (.dbg and .pdb) to the appropriate location on your debugger. These symbols are not copied during the installation; you need to get them from the installation source. Don't copy .sys files because this will confuse the debugger. They should be in subdirectory <cpu>\ntndis4 for NT4, and in <cpu>\ntndis5 for Win2000.

For Win98, the symbols are normally kept on the machine being debugged. These symbols are copied to the correct location automatically by the user interface program (ndtest.exe) when it starts. However, you need to tell the system to load those symbols. To do this, you must manually edit runwdeb.wrf or wbem.ini so it knows to load the symbols for the tester. Also make sure that it loads the symbols for ndis.vxd, as well as for your driver.

RUN TESTS

After the ndis tester files are installed, go to the installation directory and type "ndtest" to start the ndis tester user interface. Select HCT Tests and the appropriate boxes below it to run the HCT test suite. (For certification, all 6 boxes will need to be checked). To run a single script (to reproduce a problem), select Manual Tests, and check on any tests you want to run. NOTE: Some of the tests listed under Manual Tests may not normally be run as part of the certification suite. 

When running the network tests, the message card is used to communicate the test commands between the client and the server machines. In a typical test configuration, you should have three network cards in the client machine: test card, trusted card and message card, and two network cards in the server machine: server card and message card. 

On startup, ndtest.exe makes sure that the latest version of the ndistest driver (ndistest.sys or ndistest.vxd), the tditest driver (tditest.sys or tditest.vxd), and the remote connect driver (rmhapi.sys or rmhapi.vxd)  are loaded and started. It also checks to see what netcards,  ndiswan devices, and protocols are available. After this initialization, the user interface should appear on the screen. What you will see is a page with five forms. The "system" form lists information about the machine you are running on. This information will be placed into the "wrap-up" log produced by this program at the end of a test run. The "vendor" form allows you to enter the appropriate contact information concerning this card and driver. It will also be put into the wrap-up log. It is important to enter this information so WHQL can use it to contact the appropriate people if they have any questions when they do their certification tests. The third form is "LAN/ATM". It is here that you come for all your netcard tests. The "WAN/IDSN" form is used to run tests on WAN and ISDN cards. The final form is TDI Test form, which is used for running the Tdi tests. 

There are four sections on LAN/ATM form. On the left are three boxes that allow you to choose your test card, trusted card, and message card. If you are in server mode, they will be labeled server card and message card. The test card is the one on which you are running the tests -- i.e. the card you wish to certify. Any net card in your system can be used as the test card. The trusted card is a second card of the same media type as the test card, which will be used in the 2-card tests. The message card indicates which card will be used to communicate with the server during 2 machine tests. The server card is the card on the server that will participate in the 2 machine tests. The message card on the server is the card that will communicate with the client's message card during the two machine tests. After you select the test card (or the server card), ndtest will only show the valid choices for the trusted card and the message card. An information box under each selection box gives you more information about the card you have chosen.

After selecting the cards to be used in the tests, you need to select what type of tests to run. The middle section of the form is for the HCT tests. To run these tests, check the HCT Tests button at the top of this section. This is for running the certification suite. For the full test suite, the 1-card, 2-card, 2-machine, functional, stress, and performance boxes must ALL be checked. You can run a subset of the certification tests by only selecting some of these boxes. Note that you must select at least one from the top set (which cards) and one from the bottom set (types of tests). If any of the boxes are grayed out, it is because you haven't entered the trusted card or message card that is necessary for running that selection. 

There is one other box in this center section that is very important. That is the Server Mode box. You need to check this box on the machine that you are using as the ndistest server. When you do check this box, everything else except the server card and message card is grayed out -- i.e. is unavailable. What scripts you run is entirely controlled on the client side.

The rightmost section of this form is used for running individual tests (or a selection of tests). If you click on the Manual Tests button, you will see a list of available tests for you to run. The actual tests listed here depend on which cards you have selected, AND which of the 1-card, 2-card, and 2-machine boxes you have checked in the center section. You can select individual scripts to run, select them all, or clear them all. I advise that you always used Clear All before you select the individual tests to run, as the tester will remember which test(s) you selected before--and you might not want to run some of those scripts again. Note also that doing a Select All is NOT the same as running the full HCTs. Many of the scripts are not normally run during the certification tests (unless you have a full MAC driver, which you shouldn't anymore). Also, if your driver supports the Ndis4.0 receive packet method, each script you select will be run twice--once in Ndis3 mode and once in Ndis4/Ndis5 mode. During HCTs only a few scripts are run in both modes. This section is really intended for helping you reproduce problems that are found when you run the entire test suite. 

The bottom section of this form gives you information about the various test options you have chosen. It also contains a Start button, which you select when you are ready to start your test run. It also contains an Abort button, which you should select if you want to abort the current test run. Note that, when starting a test run, you should always start the tester on the server machine before you start it on the client.

The WAN/ISDN form is used to test network drivers written to the WAN miniport driver specification. This form is similar to the LAN/ATM form. The WAN/ISDN form lists all the WAN/ISDN TAPI lines instead of the cards because each WAN card may expose multiple lines. There is no trusted card. There are two additional buttons, which allow you to add numbers to call for the tests. These calling numbers are specific to each WAN category such as ISDN, Frame Relay, X.25, etc.

The TDI Test form is similar to the LAN/ATM form.  On the upper left side, you choose what interfaces you want to test over (note that only tcpip and ipx currently work).  On the lower left side, you can choose which interface to use for the messages to the server.  (You can make similar choices on the server).  Note that you can choose more than one interface to test over.  The tests will run over these sequentially.  On the right, you can select server mode, or functional and/or stress tests.  Note that there are no separate performance tests when running the tdi tests.  The Start and Abort buttons are at the bottom of the form.

Across the top of the page there are several options you might find handy. Under FILE, the SaveConfiguration option saves any information you may have entered on the VENDOR form. Under VIEW, you can select which form you want to use. This is handy if your mouse is not working, and you need to use the keyboard to move around. Under OPTIONS, you can enable or disable verbose mode using the Debug option. In verbose mode, every command sent to the driver results in a message written to the debugger that identifies the command and at least some of its arguments. This is useful when tracking down a problem, but can slow down the tester greatly. Selecting the Loop option causes the tester to repeatedly run the same script--or, if used with HCTs, to repeatedly run the selected portions of the HCT. The Viewer option allows you to set what editor is used to look at the logfiles (see RESULTS). The default is to use notepad. ResetDefaults should set all options back to their default state. Use Existing Hapi.ini is for use only with some other (internal) tests that use ndtest.exe -- you should never use it.

Under RESULTS, your first option is Test Logs. Selecting this pops up a dialog box, which shows you the latest log files of the current test card. To look at any of these files, you can either double-click the file name, or highlight it and click View Files. This will use whatever editor you have selected under OPTIONS/Viewer. The DeleteAll option allows you to delete all the old logs, presumably prior to re-running the tests. The Cancel option takes you back to the main page. The second option under RESULTS is Log Directory. It allows you to set the directory to which the logs will be copied for the current test card. By default, this is a subdirectory whose name is based on the cards name, and which is located off the installation directory. Note that if you have more than one ndistest installation on your machine, it will probably try to put all the logs off the same installation directory. If in doubt, the information box at the bottom of the form will tell you what subdirectory logs will go to. (NOTE: the logs are originally put into the installation directory. Then when the tests are completed, they are copied to the log directory. This means that if you system bugchecks, the latest logs are going to be found in the installation directory, not the log directory). The final option under RESULTS is Generate Summary. This forces the creation of whql.log. This file is normally created automatically at the end of a HCT test run.

The following are the most common popups seen with ndtest.exe:

Test Script File Not Found
-- This popup means you hit Start with Manual Tests selected, but without
-- any specific tests actually selected.

Incomplete Vendor Information
-- This popup is given at the end of a test run (or after choosing
-- Generate Summary), if you have not entered all required information
-- on the Vendor form.


The following is an example of the debugger output produced by ndtest while it is searching for available cards.

++NDTEST++ Adapter DevNode string = PCI\VEN_8086&DEV_1229&SUBSYS_00098086&REV_05\0&18
++NDTEST++ Adapter device name = {7C719979-5D24-11D2-B413-B8ADD4294F7B}
++NDTEST++ Adapter service name = E100B
++NDTEST++ Adapter Description = Intel(R) PRO/100+ PCI Adapter
++NDTEST++ Adapter driver name = D:\WINNT\System32\DRIVERS\e100bnt5.sys
++NDTEST++ Adapter alias name = E100B2
++NDTEST++ ==>CreateFile \\.\{7C719979-5D24-11D2-B413-B8ADD4294F7B}
++NDTEST++ <==CreateFile -- handle = 00000084
++NDTEST++ ==>DeviceIoControl
++NDTEST++ <==DeviceIoControl succeeded
++NDTEST++ Adapter medium type = Ethernet

The first few lines identify where ndtest is finding the card/driver. This is all registry-related information. Then, some information about the card and driver itself are listed. Next it does a CreateFile. If this fails, it usually means that the card has been removed from the system, OID_GEN_SUPPORTED_LIST is not supported, or that the driver load failed in some way, . The call to DeviceIoControl is to obtain the media type. If this call fails, then the driver was probably not able to start. If the medium type is not recognized by the tester, then that card will not be listed among the card choices. If your card is not showing up as one of the choice for test card, you should look at this debug to determine what is going wrong.

There will also be some debug generated by the search for available tdi interfaces.  It will list information for any tdi interface reported to that portion of the tester.  Here is an example:

++NDTEST++ tditest service exists

++NDTEST++ tditest status -- STOPPED

 

TdiTest Driver for Win2000 -- Built Jul 28 1999

 

TdiTest version 1.14

 

DeviceName: \DEVICE\TCPIP_{B3FCCDA2-0D47-11D3-8D6C-BA69FB4CE84E}

AddressType = TDI_ADDRESS_TYPE_IP

sin_port = 0x0000

in_addr  = 169.2.1.2

TdiPnpContext:

TdiPnpContextSize:  4

TdiPnpContextType:  3

TdiPnpContextData:  80 05 4d fe

AddressType = TDI_ADDRESS_TYPE_IPX

NetworkAddress = 0x00000000

NodeAddress    = 8.0.43.34.116.109

Socket         = 0x0000

DeviceName: \Device\Ip

OPCODE: TDI_PNP_OP_PROVIDERREADY

Bindinglist is NULL

DeviceName: \Device\Nwlnkipx

OPCODE: TDI_PNP_OP_PROVIDERREADY

OPCODE: TDI_PNP_OP_NETREADY

Bindinglist is NULL

++NDTEST++ Service started

++NDTEST++ rmhapi service exists

++NDTEST++ rmhapi status -- STOPPED

 

RemHapi Driver for Win2000 version 1.10 -- Built Jul 23 1999

 

++NDTEST++ Service started

 

NDISTEST AND TDITEST COMMANDS

The ndis tester commands are listed alphabetically, with a brief description of the command.  Commands may be omitted if they will never write an error or warning message to either the debugger or the log file. This is followed by any log messages that command may produce. Finally, any debugger messages related to this command are given. Note that the normal log messages for each command are not included. Neither are the command information messages seen on the debugger when in verbose mode, or the generic "Command failed: status = xxx" messages from the logs.

addatmaddress
This command attempts to add an alias (at the switch) for this ATM adapter. The only message generated by this command is the generic failure message. It usually means that the switch is unable to handle the request – ie, a failure of this command is almost always a switch failure rather than a driver failure.

addiproute

This command adds a “direct” route to the IP route table.   A “direct” route is one that specifies the full destination address with a full mask (255.255.255.255), with the interface and the first hop both set to the IP of the sending card.  This command is usually used with the remoteaddiproute command, which is used to establish the corresponding route back on the server.  The most likely cause of a failure in this command is using an invalid IP address for the sending card


addmulticast
This command causes the specified multicast address to be added to the list of active multicast addresses for the current open instance. It may fail if all the multicast addresses are already in use. Failures seen with command include the following:

Setmulticastlist request not supported.
-- This log message indicates that NDIS_STATUS_NOT_SUPPORTED was returned by the driver when the tester attempted to set OID_802_3_MULTICAST_LIST or OID_FDDI_MULTICAST_LIST

DoSetRequest: NdisRequest failed: returned xxxx
-- This debugger message will be given if there is an immediate failure of the request. Normally, this will probably only be seen if there is a reset in progress. Note that the tester will retry the command up to five times if there is a reset in progress.

NdtRequestComplete: BytesRead wrong on set request!"
pNdisRequest = xxxx
pNdtReqHandle = xxxx
-- This debugger message means that the driver isn't setting the BytesRead field of the NdisRequest structure correctly. The driver should not assume that this field is set to 0 on entry.

NdtRequestComplete: Error setting OID xxxx, Status = xxxx"
-- This debugger message indicates that the NdisRequest command was pended, but completed with an error. Note that much of the time this is an expected failure -- ie, the tester made a call to NdisRequest that was supposed to fail.

addparty
This command causes a call to NdisClAddParty to add another leaf to a party call initiated by the makepartycall command. This command may fail due to call manager or switch limitations. You should see the following debugger error on failure:

NdistestClAddPartyComplete: failure, status = xxxx
-- Indicates that the addparty failed, with the status message giving
-- the reason why

addwakepattern
This command adds a wakeup pattern for any driver that supports wake-on-lan with pattern matching. It may fail if all the available patterns are already in use (ie, if the card doesn't have resources available for adding another pattern). 

Add/removewakepattern request not supported.
-- This log message will be seen if the card does not support OID_PNP_ADD_WAKE_UP_PATTERN, which is the NdisRequest to set the wake-up pattern.

breakpoint
This command causes a breakpoint in the driver. You would normally add this command to a script so that you could set a specific breakpoint within your driver just before a command that would cause that breakpoint to be hit. The following message is seen on the debugger with this
command.

Command = ulBREAKPOINT
pDeviceContext = xxxx
NdisBindingHandles for open instances:
OpenBlock at xxxx had NdisBindingHandle of xxxx 

-- Identifies the breakpoint the debugger has just hit as the one associated with the "breakpoint" command. The addresses of the NdisBindingHandles should enable you to find the address of your driver structures, if necessary.

checkiproute

This command is used to check if it is possible to set up a direct route between the IP on the test machine and the one on the server machine.  It is usually used in conjunction with the remotecheckiproute command, which checks for a direct route from the server to the client.  The main cause of a failure is specifying an invalid IP address


close
This command is used to close the specified open instance that the ndis tester has open on your driver. In theory, this command should never fail. In practice, it fails fairly often. The reasons for it failing vary, but usually are the result of some process not completing as it should. Usually, there will be errors earlier in the debugger spew that will help isolate the cause of a close failure. The following debugger messages are associated with this command:

NdtCloseAdapter: Unable to close adapter, ProtocolVcContext NOT freed 
possibly due to pending sends/receives.
-- This message can occur when trying to close an open instance on connection-oriented media such as ATM, if there are open calls that will not shut down properly. Thus, the open instance itself cannot be closed. Usually, there will be other debug messages earlier in the spew that will help identify the problem.

NdtCloseAdapter: InternalNdtReqHandle not NULL on entry
pOpenBlock = xxxxx
-- This message has an associated breakpoint. It usually indicates that there was a previous reset command that never completed.

NdtCloseAdapter: NdisCloseAdapter returned xxxxxxx
NdtCloseComplete: Status = xxxxxx
-- These two messages each indicate that the call to NdisCloseAdapter failed. Hopefully, the status value will be useful in helping to track this down.

CloseWait: xxxx not shut down yet--rewaiting!
-- Indicates that 30 seconds have elapsed since the tester tried to shut down some test (or the adapter itself), but that process has not yet completed. The tester will wait for up to five minutes.

CloseWait: ERROR: timed out waiting for xxxx to shut down.
System may be left in a bad state!
-- Indicates that the 5 minutes has elapsed, and the process is still not successfully shut down. The tester will attempt to continue, but the system is probably in a bad state. It is not uncommon for the system to bugcheck shortly after this message.

NdtFreePools: tried to free packet pool with packets outstanding!
-- Indicates that we are trying to close the open instance, but there are packets that the tester tried to send that have pended but have never completed.

closeaddressfamily
This command breaks the connection between the open instance and the call manager. The following messages may be seen with this command:

FAILURE: Unable to close AddressFamily. SAP or VC still open!
-- This log message usually indicates a script problem.

NdtCloseAddressFamily: must close all associated SAPs and VCs first!
-- This debugger message indicates that there are still open VCs and/or SAPs on an address family, and that these must be deleted before the address family itself can be closed. Usually, this message will only be seen in an earlier closesap or deletevc command has failed.

NdisTestClCloseAfComplete: failure, status = xxxx
-- This debugger message indicates that something went wrong while trying to close the address family. The status value should help figure out what went wrong.

closecall
This command is used to close a normal call (not a party call). The following debugger messages are associated with this command:

NdtCloseCall: Not a valid normal call -- has leaves!
-- Usually indicates that there is an error in the calling script. Ie, it is using a closecall rather than a closepartycall command.

NdisTestClCloseCallComplete: failure, status = xxxx
-- Indicates that something went wrong while trying to close a call or a party call.

NdisTestClCloseCallComplete: done closing outgoing call
-- Indicates that the call was being closed on the originating side by the switch. This type of close should not normally happen, and may indicate that the call manager is not receiving packets on its VCs.

NdisTestClIncomingClose: incoming close received by caller!
-- Indicates that the switch has just notified the originator of the call that it is closing the call. See the message above for why this might occur.

closepartycall
This command is used to close the last connection of a party call. Ie, when there is only the sender and one leaf left. (Use dropparty to close other leaves). Some of the messages from the closecall command can also be seen with this command. The following debugger messages are unique to this command:

NdtCloseCall: Cannot close party call--multiple leaves!
-- Indicates either that there is a script error (the script needs to call dropparty for all but one of the parties of a party call), or that a previous dropparty failed for some reason.

NdtCloseCall: Not a valid party call -- no leaves!
-- Usually indicates that there is an error in the calling scripts. Ie, it is using a closepartycall command rather than a closecall command.

NdisTestClCloseCallComplete: incorrect party context!
-- Indicates that the party context carried with the ndis tester is not the same as that carried by ndis.sys. This could indicate a problem in ndis.sys or the call manager.

closesap
This command de-registers a SAP if no calls have been made on it. If a call has been made on the associate SAP, then this command deletes the endpoint that was associated with it, along with any collected data. Note that the call MUST be closed before the endpoint can be. The following debugger messages are associated with this command:

NdtCloseSap: SAP still has call associated with it!
-- Indicates that there is still an active call on the SAP. This could happen if the driver takes "too long" to call the ProtocolClDeleteVC handler when a call is being closed.

NdisTestClDeregisterSapComplete: failure, status = xxxx
-- Indicates that something went wrong when de-registering the SAP.

cosend
This command is used to start a send test over connection-oriented media (ie, ATM). It is otherwise equivalent to the send command, and all associated messages are the same as for that command.

createvc
This command creates a VC and an associate endpoint to track that VC. The following debugger message is associated with this command:

NdtCreateVC: failed to create VC. NdisStatus = xxxx
-- Indicates that the call to NdisCoCreateVc failed. The status should
-- indicate WHY.

deleteatmaddress
This command attempts to remove an alias (at the switch) for this ATM adapter. The only message generated by this command is the generic failure message. It usually means that the switch is unable to handle the request -- ie, a failure of this command is almost always a switch
failure rather than a driver failure.

deleteiproute

This command is used to remove an IP route that had been added earlier using the addiproute command.  The primary failure is due to specifying and invalid IP address

deletemulticast
This command causes the specified address to be removed from the list of active multicast addresses for the open instance. See addmulticast for the messages that can be produced by this command.

deletevc
This command deletes a VC. Note that there may not be a call active on the VC at the time this command is called. The following debugger error is associated with this command:

NdtDeleteVC: unable to delete VC. NdisStatus = xxxxxx
-- Indicates that NdisCoDeleteVc failed. The status value should give
-- a hint as to why this failure occurred.

dropparty
This command is used to remove a single leaf from a party call. Note that the closepartycall command must be used to remove the final leaf. The following log and debugger messages are associated with this command:

FAILURE: DropParty called on last leaf.
-- This log message indicates that the tester improperly tried to call dropparty when it should have called closepartycall. This is most likely a script error.

NdisTestClDropPartyComplete: failure, status = xxxx
-- This debugger message indicates that something went wrong while trying to drop a party from a party call. The status value should indicate  the cause of the problem.

endwaitforevent
This command ends an event-wait that was begun with the startwaitforevent command. It finishes if the event has occurred, or when the timeout expires. The following log messages are associated with this command:

BLOCKED: No WaitForEvent in progress! 
-- This message indicates that there was not a successful startwaitforevent
-- prior to this command. It usually indicates a script error.

getatmaddress
This command queries the call manager (and the switch) get a particular address registered for this adapter at the switch. The following log messages are associated with this command:

FAILURE: unable to get local ATM address!
-- This error message usually means that the call manager has not been able to establish a connection with the switch.

Index of address requested too large!
-- This message usually means that there was a script error -- ie, that the script requested an address with an index higher than the number of addresses available.

getevents
This command gets the number of unanticipated events that occurred while running a test. Some of the possible messages from this command are so rare that they have never been seen. The following log messages are associated with this command and have been seen:

WARNING: Received xxx unexpected calls to NdisCompleteSend
-- Indicates that some packets that weren't completed in time for an earlier test have finally completed now. Usually, there will be several debugger messages associated with the sends.

Received xxx unexpected calls to NdisIndicateReceive
-- This message is very common, especially on a busy network. Even on a quiet network there will be a few packets sent by the active protocols. These will show up in the count of this message. This message is informational only.

Received xxx calls to NdisIndicateStatus
Received xxx calls to NdisIndicateStatusComplete
-- These two messages are usually paired, with both having the same count. You should check to debugger to be sure, but the usual reason for these messages (at least on ethernet), is that resets
-- took place. Resets can cause other failures in a script. So if you see a lot of failures in a script, and the count on this message is fairly high (> 20), your card may have a reset problem.

FAILURE: hit xxx breakpoints during test
-- This message indicates that there were times during the test when either a breakpoint was hit, or one would have been hit if breakpoints had been enabled. (By default, breakpoints are disabled on the server)

getipcaptureresults
This command stops the capture of IP packets (that should've been started earlier by the startipcapture command) and returns the results of the capture. Results include : Total number of IP packets received, Total number of data bytes received in all of the packets and result of checksum verification by the tester (NOT by the card).

getnumatmaddresses
This command queries the call manager (and the switch) to see how many addresses are registered for this adapter at the switch. The only message associated with this command is the generic failure message. A failure of this command usually means that the call manager has not been able to make the connection with the switch. A return of 0 addresses means the same thing.

getperformanceresults
This command gets the results of a performance test, and writes these results to the log. The following error messages may also be written to the log by this command:

FAILURE: Opening instance not perf testing
-- Indicates either a script error, or that the script doesn't test to see if it successfully started a performance test (which could be regarded as a script error...)

FAILURE: Client send results are invalid!
FAILURE: Server send results are invalid!
FAILURE: Client receive results are invalid!
FAILURE: Server receive results are invalid!
-- Indicates that the tester was unable to retrieve at some of the results. This usually indicates that there were some problems during the test, and that the server (or the message connection between the client and the server) died during the test.

SPECIAL NOTE: Once in a great while one of the calls to the system to gets performance statistics returns an invalid number. This will usually show up as an outrageous value for the length of time taken by the test, and a 0% cpu value. For now, you can just ignore these data points.

getreceiveresults
This command displays the results of the previous receive test. The following log messages indicate an error occurred (many will have associated debugger messages):

FAILURE: OpenInstance not receiving
-- Probably a script error. The script probably did not check to be sure that the startreceive did not fail.

Warning: data may be invalid 
-- This message indicates that there seems to have been an error retrieving the results from the server machine.

WARNING: resends pended not equal to resends completed
-- Indicates that sends may not be completing properly.

WARNING: transfers pended not equal to transfers completed
-- Indicates a problem with the transfer data function. This should probably be a FAILURE rather than a warning.

FAILURE: corrupted packets received.
-- Data corruption occurred. See the debugger output for details.

FAILURE: packets resends failed
-- Some sends failed during the test. See the debugger output for details.

FAILURE: packet transfers failed
-- Indicates that some problems were seen in NdisTransferData

FAILURE: error in handle queued packets
-- Indicates that the number of packets put on the queue for further processing was not equal to the number pulled off the queue.

FAILURE: ReceiveCompletions not being indicated
-- The driver does not seem to be calling the testers ProtocolIndicateReceiveComplete handler.

getsendresults
This command retrieves the results from a send, sendpackets, or cosend test. Most failures will have debugger messages as well as the log message shown below:

FAILURE: OpenInstance not sending
-- Indicates a script error. Usually means that the script did not check to see that the send command actually succeeded before performing the waitsend and getsendresults commands.

Warning: data may be invalid
-- Indicates that there was a problem retrieving the data from the server machine. This may indicate a problem on the server machine, or with the message connection to that machine.

WARNING: pended does not equal completed
-- Indicates that not all sends completed properly. There are probably several debugger messages associated with this that will have more details.

FAILURE: there were failed sends
-- This indicates that some of the attempted sends actually failed. See the debugger messages for the reason these sends failed.

FAILURE: all sends must fail!
-- This message indicates that the driver did not fail attempted sends over a receive-only connection. (This error will be seen only with connection-oriented media that support one-way connections)

getstressresults
This command retrieves the results of a stress test and outputs them to the log. The log errors that it can record are listed below. Note that, in most cases, there will be debugger messages corresponding to the log messages. See the startstress command for these messages.

FAILURE: Endpoint not stressing
-- Usually indicates a script error, probably the script did not check to make sure the stress test started correctly.

Warning: data may be invalid
-- This message indicates that there may be been an error retrieving the data from the server machine. This could indicate a communication problem between the test machine and the server machine.

FAILURE: corrupted packets received
-- Indicates that data corruption was detected. The debugger should have more information.

FAILURE: sends pended != sends completed
-- Indicates that sends are not completing properly. The debugger should have more information on this as well.

WARNING: sends failed
-- Indicates that some sends failed. See the debugger for the reasons why.

FAILURE: transfers pended does not equal transfers completed
FAILURE: transfers failed
-- These two messages indicate that there is a problem with the NdisTransferData functioning. This is probably a driver error.

gettagdata
This command retrieves information for a particular pool tag from the information obtaine with the readmemorypool command. Warning messages are the same as for readmemorypool.

hibernate
This command puts the machine into the hibernate state. This command is currently only fully supported on Windows 2000. The following log messages are associated with this command:

BLOCKED: Helper dll not loaded!
-- Ndistest was unable to load ndtsupnt.dll. This is probably an installation problem

BLOCKED: Hibernate not supported!
-- Indicates that the machine does not support hibernate. Or, at least, that it could not perform the hibernation test. There may be another error message giving more information preceeding this one.

FAILURE: Hibernate failed!
-- The hibernation request failed for some reason. There may be a message on the debugger (although this message could be from anywhere in the system) that could help determine why hibernate failed

PowerManagement Functions not found
-- Indicates that the necessary functions could not be found in ntdll.dll. Probably means you need to update your system.

PowerState not supported
-- This machine has indicated that it does not support hibernate.

Failed to start the timer
-- Hibernate is aborted, because the tester was unable to start the
-- timer that would wake up the machine.

line_close
This command closes the specified open line device. It corresponds to TAPI lineClose function.

Syntax: $Status = line_close $CurrentLine
Parameters: $CurrentLine - The opened line device handle;
Return Value: 0 - Success, Others - Failure (same for other line_ commands)

line_drop
This command drops or disconnects the specified call. It corresponds to TAPI lineDrop function;
Syntax: $Status = line_drop $CurrentCall
Parameters: $CurrentCall - A TAPI call handle. The call state of $CurrentCall can be any state except idle;

line_get_address_caps
This command queries the specified address on the specified line device to determine its telephony capabilities. It correspnds to TAPI lineGetAddressCaps function. 
Syntax: $Status = line_get_address_caps $AppHandle $CurrentDevice $CurrentAddress $DeviceAPIVersion $ExtVersion $AddressCaps 
Parameters: $AppHandle - The handle for this TAPI application; $CurrentDevice - A DWORD variable which is the line device to be queried; $CurrentAddress - The address on the given line device; $DeviceAPIVersion - The API version number that was negotiated; $ExtVersion - The service provider-specific extension version number; $AddressCaps - The variable to receive the TAPI LINEADDRESSCAPS structure data;

line_get_address_id
This command returns the address identifier associated with an address in a different format on the specified line. It corresponds to TAPI lineGetAddressID function.
Syntax: $Status = line_get_address_id $CurrentLine $ReturnedID $LineAddressMode $Pointer $Size
Parameters: $CurrentLine - The opened line handle; $ReturnedID - The pointer variable to receive the VARSTRING type device config information; $LineAddressMode - This parameter uses the LINEADDRESSMODE_ constants; $Pointer - A variable that contains the address string; $Size - The size of the address string;

line_get_address_status
This command allows an application to query the specified address for its current status. It corresponds to TAPI lineGetAddressStatus function.
Syntax: $Status = line_get_address_status $CurrentLine $CurrentAddress $AddressStatus
Parameters: $CurrentLine - The opened line handle; $CurrentAddress - An address on the given open line device. This is the address to be queried; $AddressStatus - A pinter variable to receive the LINEADDRESSSTATUS structure;

line_get_call_info
This command enables an application to obtain fixed information about the specified call. It corresponds to TAPI lineGetCallInfo function.
Syntax: $Status = line_get_call_info $CurrentCall $CallInfo
Parameters: $CurrentCall - A TAPI call handle. The call state of $CurrentCall can be any state. $CallInfo - A pointer variable to receive the LINECALLINFO structure;

line_get_call_status
This command returns the current status of the specified call. It corresponds to TAPI lineGetCallStatus function.
Syntax: $Status = line_get_call_status $CurrentCall $CallStatus
Parameters: $CurrentCall - A TAPI call handle. The call state of $CurrentCall can be any state. $CallStatus - A pointer variable to receive the LINECALLSTATUS structure;

line_get_dev_caps
This command queries a specified line device to determine its telephony capabilities. It corresponds to TAPI lineGetDevCaps function.
Syntax: $Status = line_get_dev_caps $AppHandle $CurrentDevice $DeviceAPIVersion $ExtVersion $DeviceCaps
Parameters: $AppHandle - The handle for this TAPI application; $CurrentDevice - A DWORD variable which is the line device to be queried; $DeviceAPIVersion - The API version number that was negotiated; $ExtVersion - The service provider-specific extension version number; $DeviceCaps - The variable to receive the TAPI LINEDEVCAPS structure data;

line_get_dev_config 
This command returns an "opaque" data structure object, the contents of which are specific to the line (service provider) and device class. It corresponds to TAPI lineGetDevConfig function.
Syntax: $Status = line_get_dev_config $CurrentDevice $DeviceConfig $DeviceClass
Parameters: $CurrentDevice - A DWORD variable which is the line device to be queried; $DeviceConfig - The pointer variable to receive the VARSTRING type device config information; $DeviceClass - ASCII string that specifies the device class of the device whose configuration is requested;

line_get_line_dev_status
This command enables an application to query the specified open line device for its current status. It corresponds to TAPI lineGetLineDevStatus function.
Syntax: $Status = line_get_line_dev_status $CurrentLine $LineDevStatus
Parameters: $CurrentLine - The opened line handle; $LineDevStatus - A pointer variable to receive the LINEDEVSTATUS structure;

line_make_call
This command places a call on the specified line to the specified destination address. Optionally, call parameters can be specified if anything but default call setup parameters are requested. It corresponds to TAPI lineMakeCall function.
Syntax: $Status = line_make_call $CurrentLine $CurrentCall $CallAddr $CountryCode $CallParams
Parameters: $CurrentLine - The handle to the open line device on which a call is to be originated; $CurrentCall - The variable to receive the call handle; $CallAddr - The calling destination address; $CountryCode - The country code of the called party. If a value of 0 is specified, a default is used by the implementation; $CallParams - A variable of TAPI LINECALLPARAMS type;

line_open
This command opens the line device specified by its device identifier and returns a line handle for the corresponding opened line device. This line handle is used in subsequent operations on the line device. It corresponds to TAPI lineOpen function.
Syntax: $Status = line_open $AppHandle $CurrentDevice $CurrentLine $DeviceAPIVersion $ExtVersion $LinePriviledge $MediaMode $CallParams
Parameters: $AppHandle - The handle for this TAPI application; $CurrentDevice - A DWORD variable which is the line device to be queried; $CurrentDevice - The variable to receive the opened line handle; $DeviceAPIVersion - The API version number that was negotiated; $ExtVersion - The service provider-specific extension version number; 
$LinePrividgel - A combination of the LINECALLPRIVILEGE_ constants; $MediaMode - A combination of the LINEMEDIAMODE_ constants; $CallParams - A variable of TAPI LINECALLPARAMS type;

line_secure_call
This command secures the call from any interruptions or interference that can affect the call's media stream. It corresponds to TAPI lineSecureCall function.
Syntax: $Status = line_secure_call $CurrentCall
Parameters: $CurrentCall - A TAPI call handle. The call state of $CurrentCall can be any state. 

line_send_user_user_info
This command sends user-user information to the remote party on the specified call. It corresponds to TAPI lineSendUserUserInfo function.
Syntax: $Status = line_send_user_user_info $CurrentCall $UUInfo $UUInfoSize 
Parameters: $CurrentCall - A TAPI call handle. The call state of $CurrentCall can be any state. $UUInfo - A string containing user-user information to be sent to the remote party; $UUInfoSize - The size of $UUinfo;

line_set_app_specific
This command enables an application to set the application-specific field of the specified call's call-information record. It corresponds to TAPI lineSetAppSpecific function.
Syntax: $Status = line_set_app_specific $CurrentCall $Value
Parameters: $CurrentCall - A TAPI call handle. The call state of $CurrentCall can be any state. $Value - A dword value to be set in the dwAppSpecific member for the call's LINECALLINFO structure;

line_set_call_parameters
This command allows an application to change bearer mode and/or the rate parameters of an existing call. It corresponds to TAPI lineSetCallParameters function.
Syntax: $Status = line_set_call_params $CurrentCall $CurrentBearerMode $MinRate $MaxRate
Parameters: $CurrentCall - A TAPI call handle. The call state of $CurrentCall can be any state. $CurrentBearerMode - one of the LINEBEARERMODE_ constants; $MinRate - A lower bound for the call's new data rate; $MaxRate - An upper bound for the call's new data rate;

line_set_dev_config
This allows the application to restore the configuration of a media stream device on a line device to a setup previously obtained using LINE_GET_DEV_CONFIG. It correspnds to TAPI lineSetDevConfig function.
Syntax: $Status = line_set_dev_config $CurrentDevice $Pointer $Size $DeviceClass
Parameters: $CurrentDevice - A DWORD variable which is the line device to be queried; $Pointer - A variable that points to VARSTRING type device config information; $Size - The size of the data pointed by $Pointer; $DeviceClass - ASCII string that specifies the device class of the device whose configuration is to be set;

line_set_media_mode
This command sets the media mode(s) of the specified call in its LINECALLINFO structure. It corresponds to TAPI lineSetMediaMode function.
Syntax: $Status = line_set_media_mode $CurrentCall $CurrentMediaMode
Parameters: $CurrentCall - The TAPI call handle. The call state of $CurrentCall can be any state. $CurrentMediaMode - The new media mode(s) for the call, a combination of LINEMEDIAMODE_ constants;

line_set_status_message
This command enables an application to specify which notification messages to receive for events related to status changes for the specified line or any of its addresses. It corresponds to TAPI lineGetAddressStatus function.
Syntax: $Status = line_set_status_messages $CurrentLine $LineStates $AddressStates
Parameters: $CurrentLine - The opened line handle; $LineStates - This parameter is combination of the 
$AddressStates - This parameter is combination of the LINEADDRESSSTATE_ constants;

line_shutdown
This command shuts down the application's usage of the line abstraction of the TAPI. It corresponds to TAPI lineShutdown function.
Syntax: line_shutdown $AppHandle
Parameters: $AppHandle - A HANDLE variable which is initialized by line_initialize command; 

makecall
This command makes a call over a VC. Note that the VC must not have a call associated with it at the time the call is made. The following debugger message is associated with this command:

NdisTestClMakeCallComplete: failure, status = xxxx
-- Indicates that something went wrong while trying to make a call or a 
-- party call. The status should indicate what caused the problem.

makepartycall
This command makes the initial connection of a party call over a VC. Note that the VC must not have a call associated with it at the time this call is made. See the makecall command for debugger messages that can be seen with this command.

open
This command calls NdisOpenAdapter to get an open instance which can be used to issue commands to the driver. The following debugger message is associated with this command:

PerformOpen: NdisOpenAdapter returned xxxxx
OpenErrorStatus = xxxx
-- Indicates that something went wrong with the NdisOpenAdapter command. This could indicate a problem in ndis.sys.

openaddressfamily
This command establishes a connection between the open instance and the call manager. Debugger messages associated with this command are:

NdisTestClOpenAfComplete: failure, status = xxxx
-- Indicates that something went wrong with opening the address family.

opensap
This command registers a SAP on which a call can be received. It also sets up an endpoint to track events that may occur on that SAP, or on the VC that results from a call arriving on it. Debugger messages associated with this command are:

NdisTestClRegisterSapComplete: failure, status = xxxx
-- Indicates that something went wrong while trying to register a SAP.

performance
This command is used to start a performance test. 

The parameters are as follows for the lan version:

<TestResult> = performance Handle SendAddress PacketSize PacketCount Delay Mode TestDuration PktsPerBurst <server_handle>

SendAddress is the destination address of the packets.

PacketSize is the number of bytes in the packets.  All packets are the same size.

PacketCount is the number of packets in the test.  Many tests set this to -1 so the TestDuration will terminate the test.

Delay is the length of a delay inserted between calls to NdisSendPackets.  0 is normal.

Mode - See the scripts for examples of what is available.

TestDuration is the number of seconds the test will run.  If PacketCount is reached first then the test will stop.  If this number is 0 then only whan the PacketCount is reached will the test stop.

PktsPerBurst is the number of packets in the NdisSendPackets call.  Ndis will convert this to MiniportSend calls if the driver does not support multipacket sends.

The following messages are associated with this command:

BLOCKED: Helper DLL not loaded!
-- This message means that the operating-system specific DLL was not loaded properly. Therefore, this command cannot be performed. This probably indicates an installation problem.

BLOCKED: Send, receive, stress, or performance test already in progress
-- Only one of these tests can be in progress at a time on a single open instance. This message indicates either a script error, or that there was a problem in ending the previous test. That problem was usually on the server side. There should be some messages in the debugger of this was the case

NdtSetupPerf: pEndPoint->pPerfBlock is not NULL !
-- This debugger message means that the tester tried to start a perf test without correctly finishing the previous one. This is normally only seen if communication between the client and the server machine is temporarily disrupted.

NdtPerfSendDataDpc: packet xxxx state != available
NdtPerfSendDataComplete: packet xxxx state != sendcomp
-- These debugger messages indicate that something is going wrong with the packet queue handling. Either the queue itself is messed up, or packets are being completed more than once. They both have an associated breakpoint.

NdtPerfSendDataDpc: Aborting--no handles available
-- This debugger message is seen if there are no packets available
-- to send for an extended period of time (about 800 msec). It means 
-- that sends are not being completed properly.

NdtPerfShutdownDpc: Problems shutting down perf send tests.
PacketsPended = xxx, PacketsCompleted = xxx
-- This debugger message means that the performance test is trying to shut down, but timed out waiting for pended sends to complete. The timeout is approximately 1.5 seconds with no further sends being completed.

queryallstats
This command is used to query all the true statistics at once. It is only supported on Windows NT. The log messages are the same as with querystats below.

queryguid
This command does a WMI query on the guid associated with a given OID. Unless the particular guid being queried is a private one associated with the driver being tested, any error seen with this command is a problem with either wmi or with ndis.sys. The following log messages are associated with this command:

WmiQueryAllData failed: ulStatus = xxxx 
WmiQuerySingleInstance failed: ulStatus = xxxx
WmiOpenBlock failed: ulStatus = xxxx
-- These messages all indicate that something went wrong during the query process. Usually these indicate a bug in WMI, although it could also be a bug in ndis. If the error is ERROR_INSUFFICIENT_BUFFER (value is 0x7A or 122), then this could be a script error.

ERROR: datasize = 0 bytes!
Array size information is incorrect! [xxx]
-- This could be an error in ndis.sys. The only place this has been seen so far as been with FDDI short multicast addresses, which are not really supported by anyone.

ERROR -- returned status of 0x%08x
ERROR -- should not have succeeded!
-- These messages are seen during the test with a data buffer that is too short. This test fails on Win98 golden, but should be fixed with the first Win98 service pack.

WmiQueryAllData for ENUM_ADAPTER failed: ulStatus = xxx
-- If the status here is ERROR_INSUFFICIENT_BUFFER, it indicates that too many adapters are present for the ndis tester to handle. You might want to see what you can do to cut down the number of adapters that are being enumerated. Chances are that almost all of them are ndiswan pseudo-adapters.

queryinfo
This command calls NdisRequest with a query of a single OID. The following messages are associated with this command:

Request not supported 
-- This message is written to the log if the driver does not support the OID used in the query. Usually this indicates an error in the driver, because the tester normally only queries OIDs whose support is required and OIDs that the driver states that it supports.

WARNING: Driver failed to set bytes_returned or bytes_needed properly!
-- This log message indicates that the driver is setting one of these two fields in the NdisRequest structure incorrectly. Usually, this is a case of the driver assuming that this field was 0 on input, and adding to it rather than setting it directly. This will be changed to a FAILURE soon! (Note that there is an associated debugger message)

WARNING: Driver did not set Status correctly when passed a NULL buffer!
-- This log message indicates that the driver didn't deal properly with an NdisRequest that had a NULL buffer. This will be changed to a FAILURE in the near future. See the debugger message below for more details on this problem.

NdtRequestComplete: NdisRequest with NULL buffer status = xxxx
Must be NDIS_STATUS_INVALID_LENGTH or NDIS_STATUS_BUFFER_TOO_SHORT
-- This debugger message indicates that the driver did not deal properly with an NdisRequest with a NULL buffer. If the length of the buffer actually needed is not equal to zero, the status returned MUST be one of the two shown above. If the length of the buffer required actually is zero, then the driver may return NDIS_STATUS_SUCCESS, but it must also set BytesWritten to zero.

NdtRequestComplete: WARNING--BytesWritten[xxx] != BytesNeeded[xxx]
-- This debugger message means that the number of bytes the driver said was needed (when queried with a NULL buffer), is not the same as the number of bytes it said it wrote to the buffer when the buffer was there. Usually, this means that the driver assumed that the BytesWritten field was 0 on entry, which it is not.

querystats
This command queries the driver for global information. This query is done from user mode in WindowsNT -- ie, the ndistest driver is not involved. The following log messages are produced by this command:

CreateFile failed [xxxx]. Probably bad driver instance name
-- This message is usually seen with Win NT4.0. It usually indicates that the instance name is not related to the driver name, which means that the tester is using the wrong name to open the driver

DeviceIoControl failed. Status = xxxx
-- This message usually means that the driver does not support the OID being queried.

Request not supported
-- This message means that the driver does not support an OID that is either required or that the driver stated it did support. In either case, this is a driver error.

querystopdriver
This command checks to see if it can find the current driver in the registry list, which it must be able to do if it is going to stop the driver. Note that this command is currently supported only on Windows 2000. Log messages associated with this command include the following:

BLOCKED: Helper dll not loaded!
-- This test requires that ndtsupnt.dll has properly loaded. A failure
-- usually means an installation problem.

BLOCKED: Unable to build DevnodeTranslationList
-- Indicates that something went wrong trying to reconcile the list of
-- devices obtained from ndis and that from the registry.

FAILURE: Device node not found!
-- The device node for the device we want to stop was not found in the translation list. This could mean that the one of the guid values is incorrect in the registry.

queryvcguid
This command is similar to queryguid, except that it deals with named VCs rather than adapters. The ndistest driver names all VCs that it creates using the createvc command. This command can generate the same messages as the queryguid command. Other log messages generated by this command are given below. As with queryguid, they normally indicate a problem in wmi or in ndis, not with your driver.

WmiQueryAllData for VC list failed: ulStatus = xxx
WmiOpenBlock for EnumerateVcs failed: ulStatus = xxx
WmiOpenBlock for GUID failed: ulStatus = xxx
-- These messages all indicate that something went wrong during the query process. Usually these indicate a bug in WMI, although it could also be a bug in ndis. If the error is ERROR_INSUFFICIENT_BUFFER (value is 0x7A or 122), then this could be a script error.

readmemorypool
This command attempts to read the current state of the memory pool, to enable the tester to check for memory leaks. It is only supported for Windows NT. Possible log messages from this command are:

BLOCKED: Helper dll not loaded!
-- For whatever reason, the tester was not able to load the appropriate helper dll for this operating system. File ndtsup9x.dll is used for Windows98, ndtsupnt.dll is used for Windows NT. This message usually means that there was a problem during installation.

BLOCKED: Unable to read non-paged pool
-- This message usually means that pool tagging has not been enabled. Usually, installing the ndis tester includes the running of program "setupreg.exe", which enables pool tagging for Windows NT.


remoteaddiproute

This command sets up a “direct” IP route on the remote (server) machine—usually back to the client.  It is usually used in association with the addiproute command

 

remotecheckiproute

This command checks if a direct route exists between an IP on the remote (server) machine and another IP (usually on the client).  It is usually used in association with the checkiproute command

 

remotedeleteiproute

This command is used to delete an IP route on the remote (server) machine that was set up using the remoteaddiproute command

removewakepattern
This command removes a wakeup pattern for any driver that supports wake-on-lan with pattern matching. It may fail if all the pattern specified is not in the list. See addmulticast for debugger messages that might be seen with this command.

Add/removewakepattern request not supported.
-- This log message will be seen if the card does not support OID_PNP_REMOVE_WAKE_UP_PATTERN, which is the NdisRequest to remove the wake-up pattern.

reset
This command causes the tester to call NdisReset to reset the card. There are a lot of problems that can be caused by improper handling of this command. Many of them do not show up as reset errors. Also, resets can occur at any time without the tester issuing a reset command. If such resets are occurring with your netcard, try and determine WHY they are occurring. That may show up an error in your driver. The following debugger messages are associated with this command.

NdtReset: reset handle not NULL on entry!
pNdtReqHandle = xxxxxxxx
-- Indicates that the script tried to initiate a reset when the previous one had not yet completed. Since the timeout on the resets is about 60 seconds, this message means that the previous reset timed out. Note that the tester will NOT start a new reset when it gets this message.

NdtResetComplete: Status = NDIS_STATUS_NOT_RESETTABLE
-- This message is informational only, and indicates that the driver returned this status when ndis tries to reset it. This is only a problem if your driver does not return this status.

NdisTestProtocolStatus: Status = NDIS_STATUS_RESET_START
Received multiple RESET_START indications
-- The first part of this message indicates that a reset has just been started. It will be written to the debugger both for a reset initiated by the ndis tester, and for one initiated by the system. If a second line is also written to the debugger, it indicates that another RESET_START message was received on an open instance that was already in a reset. The usual reason for this is that the driver is sending ndis a RESET_START message. The driver ordinarily does not need to do this. Since the reset command actual comes from ndis, the driver does not need to indicate to ndis that it is resetting. Ndis sends this status indication up to the protocols all by itself. So if the driver is also sending the indication, the protocols will get two of them.

NdisTestProtocolStatus: Status = NDIS_STATUS_RESET_END
Received multiple RESET_END indications
-- This debugger message is similar to that above except that it occurs at the end of the reset process rather than at the beginning.

send
This command starts a send test over LAN media. The log messages indicate a problem with starting the test. The debugger messages can occur anytime from the start until the end of the send test. These messages are all indicated below:

BLOCKED: Send, stress, or performance test already in progress
-- This log message indicates that the tester tried to start a send test when another send-type test was already in progress. This usually indicates an error in the script, although communication problems between the client and the server can also cause this.

NdisPacketAllocateSend: NdtAllocatePacket failed
-- This debugger message means that the packet pool is exhausted, and there are no NdisPacket structures available to set up for a NdisSend. Usually, this means that there is a problem completing sends.

NdisTestProtocolSendComplete: WARNING: double completion on send
packet xxxx state != send
NdisTestProtocolCoSendComplete: WARNING: double completion on cosend
packet xxxx state != send
-- These debugger messages warn that a send has just been completed twice. This message has an associated breakpoint, so the problem can be investigated further.

NdisTestProtocolSendComplete: Late completion! 
NdisTestProtocolCoSendComplete: Late completion! 
-- These debugger messages indicate that a send completed after the wait for all the packets being completed timed out.

NdisTestProtocolSendComplete: not the right packet!
pNdisPacket = xxxx
pNdtReqHandle = xxxx
NdisTestProtocolCoSendComplete: not the right packet!
pNdisPacket = xxxx
pNdtReqHandle = xxxx
-- These debugger messages indicate that the information in the protocol reserved portion of the packet does not match that of an internal record of that packet. This message may indicate that something is trashing the protocol reserved portion of the packet structure.

NdtSendComplete: WARNING: double completion
packet xxxxxxxx state != sendcomp
-- This is a debugger message, and will be followed with a breakpoint. It indicates that something wrote to the protocol reserved portion of the NdisPacket structure whose address is included in the message between the time ndis.sys indicated the completion up to the tester, and the time when the tester is freeing the packet back to the packet pool. Usually this is due to queue mismanagement--presumably in the driver.

NdtSendDpc: WARNING: completion problem!
packet xxxxxxxx state != available
-- Similar to above message, except NdisPacket was written to while in the packet pool.

NdtSendDpc: Unable to create a send packet
-- This indicates that the packet pool is exhausted. About the only way for this to happen is for sends to NOT be completing. Under normal circumstances there are about 450 packets available in the packet pool. Thus, things have to be pretty bad for this to happen.

NdtSendEndDpc: Problems shutting down send test
PacketsPended = xxx, PacketsCompleted = xxx
-- This indicates that the driver is having a really hard time completing pended sends. The ndis tester waits until either (1) all pended sends have completed, or (2) 1.5 seconds have elapsed with NO FURTHER completions being received. As long as completions trickle in at a rate higher than one every 1.5 seconds, you should not hit this.

NdtSendComplete: 180 Send/Resends failed: status = NDIS_STATUS_FAILURE, pNdisPacket = FF8A41A8, OpenHandle FB328F28
-- This indicates that a send failed. The status should indicate the reason for this failure. The first number (180) is a running total kept per OpenHandle. After 20 only every 10th failure is printed. After 200 only every 100th failure is printed.

sendip
This command sends IP packets over LAN media to the specfied MAC address. It is important to have set the local id & remote id using the setlocalid & setremoteid commands respectively before using this command. This is due of the fact that the source and destination IP address in the IP packets sent, will be set to the local id and remote id respectively. The log and debugger messages are the same as with the send command.

sendpackets
This command is used to start a test very similar to the send test, except that the packets are sent in bursts. The log and debugger messages are the same as with the send command.

setbaudrate
This command is used to set the baud rate as used by IrDA. The debugger messages that might be seen with this command are listed under addmulticast.

Setbaudrate request not supported.
-- This log message indicates that NDIS_STATUS_NOT_SUPPORTED was returned by the driver when the tester attempted to set OID_IRDA_LINK_SPEED.

setpacketfilter
This command sets the receive packet filter to the combination specified. It will fail if any of the filters specified are not supported by the card/driver being tested. (Some combinations are tested that are expected to fail). The debugger messages that might be seen from this command are listed under addmulticast.

Setpacketfilter request not supported.
-- This log message indicates that the driver returned NDIS_STATUS_NOT_SUPPORTED when the tester attempted to set OID_GEN_CURRENT_PACKET_FILTER.

setfunctional
This command sets the functional address of an open instance on a token ring card. The debugger messages that might be seen from this command are listed under addmulticast.

Setfunctional request not supported.
-- This log message indicates that NDIS_STATUS_NOT_SUPPORTED was returned by the driver when the tester attempted to set OID_802_5_CURRENT_FUNCTIONAL

setgroup
This command sets the group address of a token ring card. This command is expected to fail if another open instance already has set the group address. (Some tests are run where this is the case). The debugger messages that might be sent under this command are listed under
addmulticast.

setlookahead
This command sets the minimum number of bytes that should be in the lookahead buffer, when a packet is received. It will fail if a value is requested that is outside the supported range. (Some values are tested that are out of this range). For drivers that use the Indicate Receive path (Ndis3.0 style receives), the lookahead requested via this command is the minimum number of bytes to be indicated up to the protocol in the Lookahead buffer. When ndis calls the driver to set the lookahead, it will add the length of the media header to this value. For example, if the tester requests a 256 byte lookahead on ethernet, ndis will request that the card set its lookahead to 270 bytes. For a netcard that uses IndicateReceivePacket (Ndis 4.0 style receives), the requested lookahead refers to the minimum length of the first buffer of the packet that is indicated up. (NOTE: the driver may always indicate the packet up with a single buffer). Once again, ndis adds the length of the media header on to the value before it calls the driver. Note that this all implies that when your driver is queries for its maximum lookahead, it should return the length of its lookahead buffer minus the media header length. The debugger messages that might be seen from this command are listed under addmulticast.

Setlookahead request not supported.
-- This log message indicates that the driver returned NDIS_STATUS_NOT_SUPPORTED when the tester attempted to set OID_GEN_CURRENT_LOOKAHEAD.

setwakeuptype
This command sets the type of netcard event which can wake up the machine. It was required under NT 5.0 beta2, but probably will not be required under beta3.

Setwakeuptype request not supported
-- The netcard driver did not recognize the request

standby
This command puts the machine into the standby state. This command is currently only fully supported on Windows NT 5.0. Most of the possible log messages are listed under hibernate; the following are associated with this command:

BLOCKED: Standby not supported!
-- Indicates that the machine does not support standby. Or, at least, that it could not perform the standby test. There may be another error message giving more information preceding this one.

FAILURE: Standby failed!
-- The standby request failed for some reason. There may be a message on the debugger (although this message could be from anywhere in the system) that could help determine why the standby failed

startdriver
This command attempts to re-start a driver that was previously stopped with the stopdriver command. Messages in addition to those shown for querystopdriver are given below:

FAILURE: device node not found!
-- Indicates that the tester can't find the parent node to re-enumerate, which would re-start our driver.

FAILURE: ReenumerateDevNode failed
Status = xxxxx
-- The call was made to the configuration manager to restart the driver, but it failed. The status should give the reason why.

startipcapture
This command starts capture of IP packets that have the source & destination IP address equal to the value set by setlocalid & setremoteid commands respectively.

startreceive
This command starts the receive process. i.e., the tester will now record (and check, if necessary) any packet arriving on this open instance. The log errors listed below are directly associated with this command. The debugger messages may occur at any time that a receive process is active.

BLOCKED: Receive, stress, or performance test already in progress
-- This log message indicates that some other receive-type tests was already in progress. That points to either a script error or an error in communicating with the server machine.

FddiCheckReceive: Dropping FDDI frame as we received FC Control Frame set to: xxx
TokenRingCheckReceive: Dropping 802.5 frame as we received FC Control Frame set to: xxx
-- These debugger messages can be seen if the tester is running in verbose mode, and a control frame gets indicated up to the ndis tester. It 

NdtReceivePacketCommon: Bad checksum of packetinfo at xx

-- This is a debugger message. It indicates that the protocol header portion of the received packet was corrupted. It also causes a breakpoint.

NdtReceivePacketCommon: Error--not enough data indicated
PacketLength = xx
PacketSize = xx
-- This is a debugger message. It indicates that the total length of the packet (as indicated up to the ndis tester by ndis.sys) is less than the value stored for the packet length as stored in the packet header. This is counted as a corrupted packet, but no breakpoint is hit.

NdtReceivePacketCommon: Error--too much data indicated
FirstBuffer = xx
PacketLength = xx
PacketSize = xx
-- This is a debugger message. It is similar to the above except that the length indicated up by ndis is greater than that stored in the protocol header. This is considered a corrupted packet, and a breakpoint is hit after the message.

NdtCheckData: mismatched data
BufferAddr = xx, offset = xx
Data was xx, should have been xx
-- This is the debugger message for the main data-integrity check done in the tester. It indicates that packet data was corrupted. A breakpoint is hit. In general, you should be able to get some idea of what caused the data corruption (or at least what kind of data corruption it is) by looking at the data at the location indicated. BufferAddr is the start of the data we are checking, and offset is the bytes into this data at which the error occurred.

NdisTestProtocolTransferDataComplete: variety of messages
-- These are the possible debugger messages hit when there is a problem in the transfer data function. There are a quite a few possible messages here, and each one should be fairly self-explanatory about what went wrong during the transfer data. There will be a breakpoint after any of these messages.

NdtReceiveDpc: Problems shutting down receive test. Memory leak possible
PacketsPended = xxxx, PacketsCompleted = xxxx
-- Some of the receive tests echo the received packet back to the sender. This message indicates that the driver is having a really hard time completing these sends. The ndis tester waits until either (1) all pended sends have completed, or (2) 1.5 seconds have elapsed with NO FURTHER completions being received.

NdtReceiveAnalyze: Lookahead too small!
Packetlength = xx
LookaheadLength = xx
PacketInfo = xx
-- This is a debugger message, and it has an associated breakpoint. It is hit when the lookahead does NOT contain as many bytes as expected. This will usually happen 14 times in a row during the stress tests. The reason is that the lookahead set with OID_GEN_LOOKAHEAD_SIZE does NOT include the media header, which is 14 bytes for both ethernet and token ring. Note that this error can also be seen if a card is using ReceivePacket indications with multiple buffers, and the first buffer does not contain at least lookahead bytes plus the media header. See also comments on the setlookahead command

startstress
This command starts the stress tests. More information on individual stress tests is available under the script descriptions. The debugger messages listed below occur during the time the stress test is executing. The log messages below occur when starting the test.

FAILURE: unable to get address of stress client
-- This log message usually indicates that there was some problem in communication between the client and server machines.

BLOCKED: Send, stress, or performance test already in progress
-- This message usually indicates a script error. It could also indicate a communication problem between the client and the server, where the last test did not shut down properly on the server.

StartStress failed: Unable to start any stress servers
-- This indicates that the tester was unable to start any of the stress servers that were specifed in the startstress command.

NdisPacketAllocateStress: NdtAllocatePacket failed
-- This debugger message means that the packet pool is exhausted, and there are no NdisPacket structures available to set up for a NdisSend. Usually, this means that there is a problem completing sends.

NdtStressClientSend: WARNING - Client increasing Server x MaxSequenceNumber to x
-- This debugger message means the client has not gotten an ACK or echo packet from the server for a while, and it is about to increase the size of the window to allow it to send a few more packets.

NdtStressClientSend: WARNING - Client marking Server x as Inactive
-- This debugger message means that the client has increased the window size 5 times, but still has not received any packets from the server. The conclusion is that the server is dead, and the client removes this server from its list of active servers. 

NdtStressClientDpc: Stress client not shutting down properly
Sends pended = xxx, sends completed = xxx
-- This debugger message means that the stress client was trying to shut down the stress test, but timed out waiting for pended sends to complete. The timeout is approximately 1.5 seconds with no further sends being completed.

NdtStressServerDpc: Stress server not shutting down properly
Sends pended = xxx, sends completed = xxx
-- Same as above, except happened on the stress server

NdtStressClientSend: WARNING: completion problem
packet xxxx state != available\n"
NdtStressSendComplete: WARNING: double completion
packet xxxx state != sendcomp
NdtStressServerReceive: WARNING: completion problem!
packet xxxx state != available\n",
-- These messages indicate a packet completion problem. See the similar messages associated with the send command

NdtStressSendComplete: Send failed, status = xxxx
-- This indicates that a send failed. The status value should indicate the reason for this failure

startwaitforevent
This command tells the ndistest driver to start waiting for a particular event to occur, and to set a flag if it does. The following messages are associated with this command:

BLOCKED: WaitForEvent already in progress!
-- The log message occurs if the script tries to start one wait event while another is already in progress. It usually indicates a script error.

NdtStartEventWait: wait already in progress!
-- This debugger message usually indicates a script error. Only one wait-event can be active at a time per open instance

stopdriver
This command calls the configuration manager to unload (or halt) the specified driver. Log messages in addition to those are querystopdriver are shown below:

Unable to get device status
-- The tester was unable to get the device status before stopping it.

FAILURE: RemoveSubTree failed
Status = xxxxxx
VetoType = xxxx
VetoName = xxxx
-- Indicates that the attempt to stop the device failed. The status message and other information may indicate why. Note that the actual call to the configuration manager changed its format about the time of NT 5.0 beta2. If you have an older version of the tester that you are using with beta2 or newer, you will probably get a status of CR_CALL_NOT_IMPLEMENTED.

stopreceive
This command stops a receive test that was in progress. The following log messages indicate a possible problem in this command:

FAILURE: OpenInstance not receiving
-- Indicates a probably script error. Probably the script did not
-- check to see that the previous startreceive didn't fail.

setoffloadtask
This command sets the tasks (tcp/udp/ip checksum, tcp largesend) to be offloaded to the network card. This command might fail if the card does not support the offloading of the corresponding task(s). See addmulticast for the messages that can be produced by this command.

tdiassociateaddress

This command associates an address object (obtained via tdiopenaddress or tdiremoteopenaddress) with an endpoint objects (obtained via tdiopenendpoint or tdiremoteopenendpoint).  This is necessary in order to establish a connection with a different endpoint.  The following message is associated with this command:

 

AssociateAddress failed due to machine mismatch

-- Indicates a script error, where the address object and endpoint object were not on the same machine.

 

tdibreakpoint

This command causes a kernel-mode breakpoint to be hit.  The breakpoint itself is in the tditest.sys driver.  This is provided so the user can set a specific breakpoint of their own anywhere in the kernel just before the following command is executed.

 

tdichecksendtest

This command checks to see if a send test, which was started by the tdistartsendtest command, has completed yet.

The following error messages may be seen with this command:

 

No send test running on this address object

No send test running on this endpoint

-- Indicates that no send test was ever started for the command to check on.

 

tdicloseaddress

This command closes an address object opened by an earlier call to tdiopenaddress or tdiremoteopenaddress

 

tdiclosecontrol

This command closes a control channel opened earlier by tdiopencontrol or tdiremoteopencontrol

 

tdicloseendpoint

This command closes an endpoint ohject opened by an earlier call to tdiopenendpoint or tdiremoteopenendpoint

 

tdiconnect

This command is used to establish a connection between two endpoints, both of which have already been associated with an address object using tdiassociateaddress.

 

tdidebuglevel

This command is used to control the level of debug output sent to the debugger. 

 

tdidisassociateaddress

This command is used to break an association, previously established with the tdiassociateaddress command, between an address object and an endpoint object.

 

tdidisableevent

This command is used to disable a previously enabled event handler for the specified address object.

 

tdidisconnect

This command is used to break a connection between two endpoints, previously connected with the tdiconnect command

 

tdienableevent

This command is used to enable an event handler for the specified address object.  Note that some event handlers apply to address objects alone (ie, for address objects that are not associated with endpoints), while some only apply to associated address objects.  This command should be used immediately after opening the address object, or just after associating and address object and an endpoint.  Most transports do not support all event types, so it is common to see this command fail with a “NOT SUPPORTED” error. 

The following event handlers can be enabled or disabled:

TDI_EVENT_CONNECT                                          – handler called when a connect request is received (for associated address object)

TDI_EVENT_DISCONNECT                                    – handler called when a disconnect request is received (for associated address object)

TDI_EVENT_ERROR                                                 -- handler called when an error occurs

TDI_EVENT_ERROR_EX                                          -- similar to above, but extra error information is available

TDI_EVENT_RECEIVE_DATAGRAM                      – handler called when a datagram is received

TDI_EVENT_CHAINED_RECEIVE_DATAGRAM   -- handler for receive path that may be used if netcard driver indicates up whole packets

TDI_EVENT_RECEIVE                                             --  handler called when data is received over a connection (for associated address object)

TDI_EVENT_CHAINED_RECEIVE                          --  handler for alternate receive path

TDI_EVENT_RECEIVE_EXPEDITED:                      --  handler for expedited data received over a connection (for associated address object)

TDI_EVENT_CHAINED_RECEIVE_EXPEDITED   --  handler for alternate receive path

TDI_EVENT_SEND_POSSIBLE                               --  handler to indicate that the protocol can again accept data to send

 

tdifetchreceivebuffer

This command is used to retrieve a buffer posted earlier with tdipostreceivebuffer.  If data has actually been received into the buffer, this data is made available to the tdigetreceivedata command

 

tdigetaddress

This command gets the address by which a provider exposed a particular interface.  This address is stored in a HAPI variable of the appropriate address type.  This address is later used to help open an address object, which will give us access to this interface.

 

tdigetdevice

This command gets the name by which the provider exposed a particular interface.  Note that this name may not actually be usable in attempting to open the interface.

 

tdigetnumdevices

This command gets the number of network interfaces of a particular address types that are exposed by the various tdi providers.  Currently, only TDI_ADDRESS_TYPE_IP (tcpip) and TDI_ADDRESS_TYPE_IPX (nwlnkipx) are fully supported.

 

tdigetreceivedata

This command allows the script to extract data from a buffer received by the tdireceive, tdireceivedatagram, or tdifetchreceivebuffer commands.  One variable at a time can be “stuffed” from this buffer until it is emptied.

 

tdigetreceiveresults

This command gets the results of a receive test that was started with an earlier tdistartreceivetest command, and was stopped by a tdistopreceivetest command.  It displays the results of the test, and can return much of the information to the script.

The following error messages may be seen with this command:

 

No receive test running on this address object

No receive test running on this endpoint

-- Tried to get the results of a receive test with having started (and then stopped) a receive test

 

tdigetsendresults

This command is used to get the results of a send test, which was started by the tdistartsendtest command, and which (presumably) has completed.  It puts the final results in the log, as well as making some of the data available to the scripts.

In addition to the error messages listed under tdichecksendresults, the following error messages may be seen with this command:

 

FAILURE:  not all sends completed

FAILURE:  there were failed sends

-- Both of these messages usually indicate that there is a problem with the netcard driver that should be investigated

 

tdigettesterversion

This command gets the current version of the tdi tester.

 

tdiisconnected

This command checks to see is the current endpoint is connected to a different endpoint.  It can be used on either the side trying to make or break the connection, or on the side which is responding the request.

 

tdilisten

This command tells an endpoint, previously associated with an address object, to be listening for an incoming connect request.  This command also instructs that endpoint on how to respond to the connect request.

 

tdiopenaddress

This command is used to open an address object, which gives us access to a particular interface exposed by a tdi provider (protocol).  With just an address object, we can send/receive datagrams.  When an address object is associated with an endpoint object, it allows us to make a connection to another endpoint and send/receive data whose receipt is guaranteed by the protocol.

 

tdiopencontrol

This command opens a control channel to a particular tdi provider.  A control channel is used for querying (and possibly setting) information that deals with the protocol as a whole, and not with individual interfaces exposed by it.

 

tdiopenendpoint

This command opens an endpoint object on a particular tdi provider.  When an endpoint object is associated with an address object on that provider, this makes it possible to establish connections over which guaranteed data transmission/reception is possible.

 

tdipostreceivebuffer

This command posts a user-mode buffer to receive a datagram or data over a connection.  This is used to test the alternate receive method of a tdi client, where the client waits for incoming data by posts a buffer to be filled with it, rather than being called when the data arrives.   This command is used in association with the tdifetchreceivebuffer command.

The following message can appear with this command:

 

BufferLength too long for PostReceiveBuffer

-- This happens if trying to post a buffer on a remote machine, and the buffer length is greater than 4096 bytes.

 

tdiqueryaddressinfo

This command queries an address object or endpoint for the its address information.  The results into a script variable if one was provided.

 

tdiqueryadapterstatus

This command queries a control channel for current adapter status.

 

tdiquerybroadcastaddr

This command queries a control channel for the network address used to send broadcast datagrams.

 

tdiqueryconnectioninfo

This command queries an endpoint for its connection information

 

tdiquerydatagraminfo

This command queries a control channel or address object for its datagram capabilities

 

tdiquerydatalinkaddr

This command queries a control channel for its datalink address.

 

tdiqueryfindname

This command queries a netbios address object for its name.

 

tdiquerymaxdatagraminfo

This command queries a control channel or address object for information concerning the maximum datagram size

 

tdiquerynetworkaddr

This command queries a control channel for the network address.

 

tdiquerysessionstatus

This command queries a control channel for the current session status information.

 

tdiqueryproviderinfo

This command queries a control channel for information about the provider.  This information is placed in a HAPI variable if provided, making it accessible by the scripts.

 

tdiqueryproviderstats

This command queries a control channel for statistics that may have been maintained by that network protocol.

 

tdireceive

This command checks to see if the receive handlers have received any data.  If data has been received, it puts that data into a buffer that can be accessed with the tdigetreceivedata command.

 

tdireceivedatagram

This command checks to see if a datagram has been received by the ReceiveDatagramHandler.  If one has been received, it puts the address of the sender into a passed-in variable, and puts the data into a buffer that can be accessed with the tdigetreceivedata command.

 

tdireleasememory

This command frees (releases) a block of kernel memory that was later set aside with the tdireservermemory command

 

tdiremotedebuglevel

This command sets the level of debug output on a remote machine (server).  Otherwise it is the same as the tdidebuglevel command

 

tdiremotegetaddress

This command gets the address of a protocol interface on a remote machine.  Otherwise it is the same as the tdigetaddress command

 

tdiremotegetdevice

This command gets the name of a protocol interface on a remote machine.  Otherwise it is the same as the tdigetdevice command

 

tdiremotegetnumdevices

This command gets the number of interfaces of a particular address type exposed on a remote machine.  Otherwise it is the same as the tdigetnumdevices command

 

tdiremoteopenaddress

This command opens an address object on a remote machine.  Otherwise it is the same as the tdiopenaddress command

 

tdiremoteopencontrol

This command opens a control channel on a remote machine.  Otherwise it is the same as the tdiopencontrol command

 

tdiremoteopenendpoint

This command opens an endpoint on a remote machine.  Otherwise it is the same as the tdiopenendpoint command

 

tdiremotereleasememory

This command causes a remote machine to release a block of memory previously reserved with the tdiremotereservememory command.  Otherwise it is the same as the tdireleasememory command

 

tdiremotereservememory

This command causes a remote machine to set aside a block of non-paged pool memory for later use.  Otherwise it is the same as the tdireservermemory command.

 

tdireservememory

This command sets aside a block of kernel (non-paged pool) memory for later use, or to simulate a low memory situation.  It will fail if there is insufficient memory available to satisfy the request.

 

tdisend

This command sends a single block of data over an established connection.    It is assumed that the receiver will know how to interpret the data sent

The following error message may be seen with this command:

 

Too much data to fit in data buffer

-- This error occurs if the script tries to send more than 4096 bytes

 

tdisendbuffer

This command is basically the same as tdisend, except that the kernel maps the data in the user-mode buffer and then sends directly, rather than copying the data into a kernel mode buffer first.

 

tdisenddatagram

This command sends a single datagram over the current address object to the address specified.  It is assumed that the receiver will know how to interpret the data sent.

The following error messages may be seen with this command:

 

Transport Address type invalid for this address object

-- This error occurs if the address type of the current address object is different than the specified destination

Too much data to fit in data buffer

-- This error occurs if the script tries to send more than 4096 bytes

 

tdisenddatagrambuffer

This command is basically the same as tdisenddatagram, except that the data is sent directly from the mapped the user-mode buffer, rather than copying the user-mode data into a kernel-mode buffer first.

 

tdistartreceivetest

This command starts a receive test on an address object or a connection.  During a receive test, it will count (and possibly verify) all data that is received, and then discard it.  This command is used in association with the tdistopreceivetest and tdigetreceiveresults command.  A tdisendtest must be running with this address object or connection as the target in order for data to be received.

The following error messages may be seen with this command:

 

Already running receive test on this address object

Already running receive test on this endpoint

-- Only one receive test can run at a time on any given address object or endpoint.  (Note that multiple tests can be run using different address objects or endpoints)

 

tdistartsendtest

This command starts a send test running on this address object or endpoint.   The test will run until it completes or is stopped by the tdistopsendtest command.  It assumes that there is a tdireceivetest running to receive and analyze the data.

The following error messages may be seen with this command:

 

Transport Address type invalid for this address object

-- The address type of the address object did not match the destination

Already running send test on this address object

Already running send test on this endpoint

-- Only one send test at a time can run on an endpoint or address object (NOTE:  but you can run one on each of the current endpoints/address objects available)

 

tdistopreceivetest

This command stops the receive test currently running on this address object or endpoint.  Usually this command is followed by a tdigetreceiveresults command.

The following error messages may be seen with this command:

 

No receive test running on this address object

No receive test running on this endpoint

-- Tried to stop a receive test that had not been started

 

tdistopsendtest

This command stops a send test that was started by a tdistartsendtest command.  For possible error messages, see tdichecksendtest.

waitperformance
This command waits for a performance test to complete. The following
log messages are associated with this command:

FAILURE: called waitperformance with no performance test active. This message usually indicates a script error (the script forgot to check and see if the performance test successfully started)

waitstress
This command waits until the current stress test has completed. The following log errors can be seen with this command.

FAILURE: called waitstress with no stress test active
-- This usually indicates either a script error, or that communication between the client and the server machine is having a problem

waitsend
This command waits until a send (includes sendpackets and cosend) test has completed. The following log errors can be seen with this command:

FAILURE: called waitsend with no send active
-- This message usually indicates a script error, or a case in which the script didn't verify that the send command was successful before issuing the waitsend

wan_addline
This command configures this TAPI line to be enabled on the server side. 
Syntax: wan_addline $DeviceID
Parameters: $DeviceID - An interger variable which is the TAPI line device ID to be enabled on the server;

wan_addlink
This command bundles another connected call. 
Syntax: $Status = wan_addlink $BundleHandle $CurrentCall
Parameters: $BundleHandle - A NDISWAN bundle handle for a group of calls; $CurrentCall - A TAPI call handle;

wan_answercalls
This command prepares the remote server to answer incoming calls with a specific mode.
Syntax: $Result = wan_answercalls $RemoteOpen $AnswerMode
Parameters: $RemoteOpen - The remote server open instance handle;

wan_gethandle
This command gets the NDISWAN handle from the TAPI call handle. This command works on Windows NT only.
Syntax: $Status = wan_gethandle $CurrentCall SELECT_BUNDLE $BundleHandle
Parameters: $CurrentCall - A TAPI call handle; $BundleHandle - A variable to receive the NDISWAN bundle handle corresponding to the TAPI call handle.

wan_gethdcall
This command gets the PPPMAC handle from the TAPI call handle. This command works on Windows 9x only.
Syntax: $Status = wan_gethdcall $CurrentLine $CurrentCall $BundleHandle
Parameters: $CurrentLine - The opened line handle; $CurrentCall - A TAPI call handle; $BundleHandle - A variable to receive the PPPMAC handle corresponding to the TAPI call handle;

wan_route
This command enables the work card operation over the estabilished call. This command works on Windows NT only.
Syntax: $Status = wan_route $CurrentCall $G_WorkCard
Parameters: $CurrentCall - A TAPI call handle; $G_WorkCard - The global variable set by the NDISTEST UI;

wan_setworkcard
This command sets the work card instance name. The $G_WorkCard global variable is initialized by the NDISTEST UI.
Syntax: $Status = wan_setworkcard $G_WorkCard
Parameters: $G_WorkCard - An string variable which contains the WAN work card instance name;

wan_startserver
This command starts the remote server operation. 
Syntax: $Result = wan_startserver $RemoteOpen
Parameters: $RemoteOpen - The remote server open instance handle;

wan_stopserver
This command stops the remote server operation.
Syntax: $Result = wan_stopserver $RemoteOpen
Parameters: $RemoteOpen - The remote server open instance handle;

wan_unroute
This command disables the work card operation . This command works on Windows NT only.
Syntax: wan_unroute $BundleHandle
Parameters: $BundleHandle - A NDISWAN bundle handle obtained from WAN_GETHANDLE; $G_WorkCard - The global variable set by the ndtest.exe;

Other Failures (not associate with any command)
These debugger messages can occur at any time. They are not associated with any specific command.

NdtIssueRequest: IRP buffer size mismatch!
DLL and driver are mismatched!
-- This message indicates that ndistst.dll and ndistest.sys are mismatched. This usually indicates that something went wrong with the installation process.

RecordCompleteIrp: IRP not found!
-- This debugger message usually means that we are about to try and complete an IRP twice. The results are usually fatal. Please report these, as they indicate an error in the ndis tester.

CheckForIrpNotComplete:
pIrp = xxxx
pSendBuffer = xxxx
pReceiveBuffer = xxxx
Command = xxxx
-- This debugger message indicates that there were still outstanding IRPs when the tester was being shut down. These usually indicate some problem in the ndis tester. Please report these.

NdisTestProtocolStatus: Status = xxxx
-- This message is writen to the debugger whenever ndis or the driver indicates a status up to the tester's ProtocolStatus handler. The message will describe the status that is indicated up.

<FunctionName>: unable to allocate <blockname>
-- This message indicates that the system was unable to satisfy a memory allocation request from the tester.

NdtFreeMemory: memory block already freed!
-- This message indicates that the tester tried to free a memory block that was already freed. It has an associated breakpoint. At the breakpoint, get a stack dump, then hit "g" to continue. Send us the stack dump so we can fix the problem.

NdtFreeMemory: trailer overwritten for block staring at xxxx
-- This message indicates that something wrote past the end of this memory block. There is a breakpoint associated with this message. Please follow the procedure for the message above.

The following memory blocks have not been freed!
-- If you get this message at the end of a normal test run, where everything passed, then send us the debug from this message thru all the "memory block" messages that follow. If you have failures, then these messages are expected. In that case, we don't want to see them.

ERROR: Unable to load dll ndistst.dll
error = 0x0000045a
-- This popup usually indicates that the ndis tester DLL is a different version than the ndis tester driver. This problem may arise from having multiple versions of the tester on your machine, and loading the wrong driver. Or, something may have gone wrong during installation. The best thing to do is remove all old copies of the tester from your machine and re-install and reboot.

Implementing Support for Media Sense

The overall rule to follow for media sense is:  Indicate a media event only if a change state has occurred. The following describes applicable scenarios.

Connect/Disconnect

 

Reset

·        If a connected device is reset, it should not generate any disconnect or connect events. (This is the preferred method).  Or it can generate one disconnect and one connect event.  If it generates a connect event, then this should happen within two seconds of reset completion.

·        If a disconnected device resets, it should not generate any disconnect events.

 

Halt

 

Load

 

Sleep

 

NOTES:

 

GENERAL TEST SCRIPTS

The general scripts are those that are found in the "scripts" subdirectory. These are run for LAN, ATM, and IrDA media types. Only NdisWan does not use these scripts. 

nd_cli.tst

This is the master script for the client. Its main purposes are to find the test and trusted cards, to verify that the driver is of the correct Ndis version, and to check for memory leaks. Note that nd_cli.log actually contains the logs for several of the scripts that it calls. Specifically, it contains the log data from nd_gtest.tst, nd_gtrst.tst, and nd_lan.tst or nd_atm.tst or nd_irda.tst. So if you are trying to track down an error in nd_cli.log, the error may actually have occurred in one of those other scripts.

The most common warnings and errors encountered in this script are:

FAILURE: Only miniport drivers can be certified.
-- The tester will still run on full MAC drivers, but WHQL will not certify them. Note that the plan is to discontinue support for MAC drivers after Windows2000.

FAILURE: Inappropriate Ndis version for driver on this platform.
Driver Ndis Version was x.x, must be at least y.y.
-- OID_GEN_DRIVER_VERSION/OID_GEN_CO_DRIVER_VERSION returns the Ndis version for which the driver was written. To be certified for Windows2000 or Win98, this must be Ndis 5.0. For NT4.0, Ndis4.0 is required. .

TEST ABORTED: cannot run stress or performance tests on a busy net.
-- Because the stress and performance tests can saturate the net, this test provides a safety net so you don't accidentally start these tests on a busy net.

WARNING: possible memory leak for tag xxxx
starting blocks = xx, ending blocks = xx
starting bytes = xx, ending bytes = xx
-- This message warns of a potential memory leak that may be related to your driver. The ndis tester takes a memory snapshot at the beginning and end of the test run. If any memory tag shows a usage increase, this warning will be given. An increase of up to four blocks is probably just coincidence--one of the loaded protocols might have done something at exactly the wrong time. But any increase of more than 5 blocks should be investigated. This is especially true if the tag is one that your driver uses when it is allocating memory.

nd_fdsrv.tst

This script is called by nd_lan.tst, nd_atm.tst, or nd_irda.tst on the client machine, to try and establish a connection with the server machine. If you compare this script to nd_srv.tst, you can follow the steps used in setting up the connection between the client message card and the server message card. Its log information will be in nd_cli.log.

If your client and server are unable to establish a connection, you will probably see the following message in nd_cli.log:

Timed out waiting for 1st response
-- Either there is a connection problem (i.e., cables), or the client and server machine are running different versions of the Ndis tester. Check nd_srv.log to determine which.

nd_gtest.tst

This script is called by nd_cli.tst to verify that the device designated as the test card really exists, and can be opened successfully. It also determines what media type(s) are supported by the device. Results are logged in nd_cli.log. Errors in this script are fatal; i.e., they result in the test being aborted. The popups associated with each error are pretty self-explanatory, and they are very rarely hit. It you do hit an error in this script, it may be due to the driver being unloaded.

nd_gtrst.tst

This is similar to nd_gtest.tst except that it is used for the trusted card. The most common error here occurs if the test card and the trusted card are not able to communicate. Usually this is a result of a cabling error, although sometimes it may indicate a configuration problem.

nd_srv.tst

This is the master script for the server. Its purpose is to start up the server work card and the server message card, and to establish communication between the client and the server. Note that the server never initiates any communication--it only responds to messages from the client. Normally you don't need to look at its log file (nd_srv.log), but it might help you if you are unable to get the client and server to connect.

If the client and server are unable to connect, look in nd_srv.log for one of the following messages:

Initial Packet Invalid
-- Usually means that your client and server machines are running different (probably incompatible) versions of the ndis tester. You should re-install.

Timed out waiting for second packet
-- Usually indicates that there is a problem either sending on the server message card or receiving on the client message card. Much rarer, but possible, is that the client got a response from more than one server, and chose a different one.

LAN FUNCTIONAL SCRIPTS

1c_filtr.tst, 1c_funct.tst, 1c_gguid.tst, 1c_ginfo.tst, 1c_group.tst, 1c_gstat.tst, 1c_gtime.tst, 1c_looka.tst, 1c_multi.tst, 1c_ofldn.tst, 1c_open.ctst, 1c_reset.tst, 1c_sends.tst, 1c_srecv.tst, 1c_srbrd.tst, 1c_srdir.tst, 1c_srfun.tst, 1c_srgrp.tst, 1c_srmul.tst, 1c_srpro.tst,  1c_srrbr.tst

2c_rmult.tst, 2c_slook.tst, 2c_spack.tst, 2c_srecv.tst, 2c_srbrd.tst, 2c_srque.tst, 2c_srrbr.tst, 2c_stran.tst

2m_addre.tst, 2m_ckslg.tst, 2m_cksum.tts, 2m_dlock.tst, 2m_hiber.tst, 2m_lgsnd.tst, 2m_load.tst, 2m_media.tst, 2m_misc.tst, 2m_prior.tst, 2m_srecv.tst, 2m_srbrd.tst, 2m_srrbr.tst, 2m_stndb.tst, 2m_wollk.tst, 2m_wolmp, 2m_wolpt.tst

The LAN scripts are used for testing Ethernet, Tokenring, and FDDI drivers. They are also used for testing intermediate miniports such as AtmLane. The comments below look at these scripts in the approximate order in which they are called. Note that reset-related problems (which can potentially occur at any time) are discussed under 1c_reset.tst. General send failures, which can occur with any send or send-receive test, are discussed under 1c_sends.tst. Finally, receive related problems are discussed under 1c_srecv.tst.

nd_lan.tst

This is the master script for all LAN media. It does not produce its own log file -- its data is written to nd_cli.log. It deals with the setup necessary to run a single LAN script, as well as running the full test suite. There are no failures or warnings in this script, but some of the nd_xxx scripts that it calls can put them into nd_cli.log. The following popup can be encountered:

Can no longer communicate with server. Tests will terminate.
-- This can happen if loading and unloading (starting and stopping) the test driver somehow causes the client message card to lose its connection with the server message card. If you encounter this problem, make sure that you are not using the test card as the client message card.

nd_ck2cr.tst

This script is used to see whether the test driver uses the Ndis3.0 receive path (receive indications) or the Ndis4.0 receive path (receive packet indications). If you are running individual scripts, and your card supports the Ndis4.0 receive path, then 2 card scripts will be run in both modes. If you are running the HCTs, then only a few scripts will be run in Ndis3.0 mode.

If your card is dropping a lot of packets, you might see the following error (in nd_cli.log) generated by this script:

FAILED: Unable to determine whether card supports ReceivePacket indications or not. There was probably an error. Investigate whatever command above failed.
-- This is usually caused by too many packets being dropped. Check the commands preceding this error message to determine if this is the problem. Another problem that can occur is that the test card "went deaf" somewhere between when we originally checked to see if the trusted card could talk to the test card and this point. If that is the case, there will be no packets received in either the "receive" or the "receivepacket" portion of this test.

nd_ck2mr.tst

This script is almost identical to the one above, except that it checks for support of receivepacket when running 2 machine tests. Note that if you are running individual tests, 2 machine tests are NOT run in both Ndis3.0 and Ndis4.0 mode--they are run in whatever mode the card actually uses. Failure information is the same as that with the script above.

nd_cktrs.tst

This script is called by nd_cli.tst to make sure that the trusted card can talk to the test card. The most likely problem for you to see with this script is the following popup:

Check on connection with trusted card.
OK to continue, Cancel to abort.
-- This happens if you have specified a trusted card, but the packets sent by the trusted card are not received by the test card. The popup gives you the chance to verify that your cables are correct. If you choose OK, the tester will retry the test. If you choose Cancel, then the tester will continue, but all 2-card tests will be skipped.

nd_ginfo.tst

This script is called by nd_lan.tst to collect a bunch of information about the test card (and trusted card, if there is one) that will be needed to run other tests. Specifically, this script queries the appropriate OIDs to get the maximum lookahead, the maximum total packet size, and the current address. If any of these queries fail or give and invalid value, an error will be written to nd_cli.log and the tests will be aborted. The possible errors from this script are pretty self-explanatory, as they all relate to a query failing in some way.

1c_filtr.tst

This script tests to make sure that the driver can set the receive filter to any of the possible values defined for that media type, whether or not they are supported by the card/driver. It verifies that the driver returns NDIS_STATUS_SUCCESS if the filter is supported, or an appropriate error if the filter is not supported. It also checks to make sure that querying the driver for the current filter setting returns the expected result.

In general, very few drivers fail this test. When there are failures, they are usually due to some problem with resetting the card. If this is the case, the debugger will show a series of NDIS_STATUS_RESET_START and NDIS_STATUS_RESET_END messages. There may also be some NDIS_STATUS_ABORTED or NDIS_STATUS_RESET_IN_PROGRESS messages mixed in. If you see this, you need to investigate WHY your driver is resetting.

1c_funct.tst (Token Ring only)

This script tests the ability of token ring drivers to set the current functional address on multiple open instances. It also verifies that a query of the driver returns the correct functional address for that open instance. This script will generate errors if the driver is unable to set or clear a particular functional address. Errors on this script are very rare. If any do occur, the error message should be self-explanatory.

1c_gguid.tst

This script tests the querying of driver information using WMI. Since the WMI system was not part of Win95 or NT4.0, this test only has meaning for Win98 and NT5.0 In general, this script is testing ndis.sys and WMI rather than your driver. If your driver exports any private GUIDs to WMI, then you need to look at the last few variations to make sure your driver is handling these correctly. The test uses a QueryGlobalStatistics call with OID_GEN_SUPPORTED_GUIDS to get the list of private GUIDs exported by your driver. It then attempts to query these GUIDs using WMI. The tester will report an error if the WMI query fails. If it succeeds, you need to look at the results to make sure it worked correctly.

There were several errors in WMI queries in Win98 golden. When running this test under Win98, for each query you will see the message:

WARNING: bytes needed not set correctly.
-- This is because of an error in Win98 when calling WMI with a NULL buffer. It incorrectly calculated the number of bytes actually needed to store the response. In addition, the WMI queries for OID_802_3_MULTICAST_LIST and (probably) OID_FDDI_LONG_MULTICAST_LIST will fail due to a related error in WMI. There may also be problems in the queries for OID_802_3_MAC_OPTIONS and the various OID_FDDI_SHORT_xxx queries.

There is also one known error in WMI queries for NT5.0 beta2. The WMI query for OID_802_3_MAC_OPTIONS will fail.

1c_ginfo.tst

This script performs a series of NdisRequest calls to the driver, to verify that it supports the querying of all required information OIDS, and that any optional OIDS that it claims to support it actually does. As with 1c_gstat.tst, you need to verify by inspection that the values returned for the various OIDS are correct. Especially look at the value returned for OID_GEN_VENDOR_DESCRIPTION, as it is very common for badly formed strings returned as a result of this query. The most common errors in this script are:

FAILURE: required oid "OID_NAME" not found in supported list.
-- Either your driver does not support a required OID, or you forgot to add this OID to your supported list. Be aware that the list of required OIDs has grown from PC97 to PC98. The most OIDs usually missing are: OID_GEN_MEDIA_CONNECT_STATUS, OID_GEN_MAXIMUM_SEND_PACKETS, OID_GEN_VENDOR_DRIVER_VERSION

FAILURE: unable to query "OID_NAME"
-- The driver claimed to support an OID but the query failed.

1c_group.tst (Token Ring Only)

This script tests the ability of token ring drivers to set or clear the single group address on the card. Note that even newer cards (whose hardware could support multiple group addresses) are required to support just the single group address. Most of the errors on this script indicate a failure to keep track of which open instance actually "owns" the group address. (Since there is only one group address available on the card, the open instance that first sets it owns it until it clears the group address.)

1c_gstat.tst

This script gets the list of OIDs supported for QueryGlobalStatistics, and proceeds to query all of them. It then proceeds to do a QueryAllGlobalStatistics. Note that the tester is unable to verify most of the values returned for the queries done in this test (especially for the true statistics). It is up to the driver writer to verify that the values being returned are correct. The most common errors in this script are:

FAILURE: required oid "OID_NAME" not found in supported list.
-- Either your driver does not support a required OID, or you forgot to add this OID to your supported list. Be aware that the list of required OIDs has grown from PC97 to PC98.

FAILURE: unable to query "OID_NAME"
-- The driver claimed to support an OID but the query failed.

FAILURE: unable to query all statistics
-- If there are no other failures, this probably indicates a problem in Ndis.sys. Note that there was an error in the ndis.sys for NT4.0sp3 that would result in this error if your driver supported private OIDs with values of the form 0xff02xxxx.

The most common error seen with the actual data returned is with OID_GEN_VENDOR_DESCRIPTION. Make sure that the string returned is what you expect.

1c_gtime.tst

This script verifies that the initialization time for a network card is not too long. It tests the cable disconnected case first and then the cable connected case. The common failures seen with this script are similar to the ones in 2m_media.tst.

1c_looka.tst

This script verifies that the lookahead length on your card can be set to everything up to -- but NOT exceeding -- the value returned from OID_GEN_MAXIMUM_LOOKAHEAD. Note that this script is not verifying that the card is actually using this value correctly. That is done in another script. The most common problems seen with this script are:

FAILURE: queryinfo returned xx, expected yy
-- after setting the lookahead, a query of OID_GEN_CURRENT_LOOKAHEAD returned a value LESS than the requested lookahead. This would indicate that your card/driver did not set the lookahead correctly.

WARNING: queryinfo returned xx, expected yy
-- after setting the lookahead a query of OID_GEN_CURRENT_LOOKAHEAD returned a value GREATER than the requested lookahead. This is valid if your driver uses a fixed lookahead, and always returns that fixed value. It is also valid if your driver always returns the lookahead value the card is actually using, which would be the largest value that any of the open instances on that card has set. In any other cases, you would need to investigate, as your card/driver may not be setting the lookahead correctly.

FAILURE: should not be able to set the lookahead to xx
-- This error occurs if an attempt to set the current lookahead to a value greater than that returned by OID_GEN_MAXIMUM_LOOKAHEAD returns NDIS_STATUS_SUCCESS. This is most commonly seens with drivers that use a fixed lookahead. Note that even drivers that use a fixed lookahead MUST FAIL any attempts to set the lookahead to a value higher than the maximum.

1c_multi.tst (Ethernet and FDDI only)

This script tests the ability of ethernet and FDDI drivers to set up multiple multicast addresses. It does not test to see that the card is actually able to receive on all these different addresses (that comes later). It just verifies that multicast addresses can be set (and deleted), and that a query will return the correct list. The most common problems seen with this script are:

FAILURE: must support at least 32 multicast addresses
-- This is a relatively new requirement for Win98 and NT5.0. 

FAILURE: unable to add multicast address
FAILURE: unable to delete multicast address
FAILURE: open x multicast list should have yy entries
-- These failures usually occur together, and often there will be a great number of them (especially the third one). When this occurs, it means that your driver did not have as many multicast addresses available as it claimed. There could be a several reasons for this. 1) Your driver did not correctly return the list size; 2) The query for the number of addresses in use returned an incorrect value; 3) Some protocol grabbed a multicast address between the time the script queried for the number in use and the point at which the script tried to use that "slot". This can happen if this script is run immediately after another script which unloads/loads (or stops/starts) the driver. This won't happen when running the HCTs, but could happen when running a series of individual scripts. This problem was encountered quite frequently with the old script 1c_load.tst, which is one of the reasons that script was replaced.

1c_ofldn.tst

This scripts verifies the ability of the miniport to respond correctly to certain incorrect queries/set requests to OID_TCP_TASK_OFFLOAD
Sample incorrect requests include :
-- Query with an invalid task offload version
-- Query with unspecified encapsulation type and flag error if the miniport reports TCP largesend task offload capability 
-- Set request for an unsupported task offload capability
Problems specific to this script are :

WARNING : Invalid Task Offload version NOT detected !!!
-- The query to OID_TCP_TASK_OFFLOAD with an invalid Version (a field in NDIS_TASK_OFFLOAD_HEADER) was not detected by the miniport 

FAILURE : Invalid TcpLargeSend & UNSPECIFIED_Encapsulation combination NOT detected !!!
-- The query to OID_TCP_TASK_OFFLOAD with Encapsulation (a field in NDIS_ENCAPSULATION_FORMAT) set to UNSPECIFIED_Encapsulation was returned with support for TCP LargeSend capability.This is invalid.

FAILURE: Unsupported Checksum Offload combination NOT detected !!!
FAILURE: Unsupported TCP LargeSend Offload combination NOT detected !!
-- The set request to OID_TCP_TASK_OFFLOAD with the offload capability unsupported by the miniport was successful. This should not  happen, ie. the card must fail this set request.

1c_openc.tst

This script verifies the ability to open and close an adapter multiple times. Actually, miniport drivers are opened once (by ndis.sys), so this script really is testing ndis, not the driver. If your driver is a miniport (and all netcard drivers should be at this point), then any failure in this script is probably an error in ndis and needs to be reported. 

1c_reset.tst

This script attempts to reset the card multiple times while at the same time sending lots of packets over that card. It tests to make sure that that card can reset itself and that it deals properly with packets that have been given it to send when interrupted by a reset. This is probably the single script that causes the most problems with drivers. Note that some of the problems listed here can also occur if the card is reset at any other point during the tests. These other resets do not occur based on a NdisReset command from the tester or a protocol, but are usually instigated by ndis.sys because sends appear to be stalled on the card. Some of them are also caused by the miniports CheckForHang handler returning TRUE. A reset for a Token ring card can be triggered by a status indication of NDIS_RING_LOBE_WIRE_FAULT, NDIS_RING_HARD_ERROR, or NDIS_RING_SIGNAL_LOSS. A token ring card must be careful not to indicate any of these statuses to ndis as a result of a reset, or it could easily get stuck in a loop where it is continuously resetting.

1c_sends.tst

This script tests the ability to send data, both singly and in bursts. It tries sending to all the various address types supported by the media type of the current driver. As far as it is concerned, no one is listening to the data being sent. The problems listed below can occur with any of the send or send-receive tests. Note that most problems with sends will result in debugger messages as well as log messages.

FAILURE: should have sent xx packets
-- This usually only happens when a send test is aborted. A packet is counted as "sent" as soon as the NdisSend or NdisSendPackets call is made. A send failure does not affect this count.

1c_srecv.tst

This script tests for the ability to receive loopback packets with a variety of address types on a variety of filter settings. It uses one open instance to send and eight to receive. Each of the eight has a different filter setting. This way all supported filter settings can be tested quickly, with the bonus that we are also testing to make sure that there is no "crosstalk" -- i.e., that an open instance receives a packet that it should not. Most of the problems listed here are common to the rest of the send/receive scripts as well, so they are only listed here.

WARNING: should have received xx packets.
-- This indicates that some packets were dropped, but not enough to cause the test to fail. You will get a warning if packets were dropped, but at least 95% of the packets were received.

FAILURE: should have received xx packets.
-- This message is similar to that above, except that more than 5% of the packets were dropped. This results in the test failing rather than just getting a warning. 

FAILURE: no packets should have been received.
-- This message indicates that some "crosstalk" occurred -- ie, that an open instance received data that should only have been received by a different open instance. If NONE of the 8 receiving open instances should have received this packet, it may indicate a bug in your driver. Otherwise, it may indicate a bug in ndis.sys. For example, Win95 and Windows NT4sp3 will both get this error if testing an invalid group address, because of an error in the group address filter handling in their version of ndis.

1c_srbrd.tst, 1c_srdir.tst, 1c_srfun.tst, 1c_srgrp.tst, 1c_srmul.tst, 1c_srpro.tst

These scripts test loopback of packets with a particular address type. They are normally only done for cards that handle their own loopback and for full MAC drivers, although they can be run individually for any LAN card. The problems seen with these cards are addressed above.

1c_srrbr.tst, 1c_srrdi.tst, 1c_srrfu.tst, 1c_srrgr.tst, 1c_srrmu.tst

These scripts, which do additional loopback testing, are only done for full MAC drivers.

2c_rmult.tst

This script tests that the card can actually receive on as many different multicast addresses as it claims to support. It uses up all available multicast addresses, and then tries to send packets to each of those addresses. It checks to make sure that packets are only receive on those multicast addresses that are actually active. This test requires that both trusted card and test card be miniports. The following messages may be seen in the log:

FAILURE: driver must support at least 32 multicast addresses
-- This is a new requirement for PC98. Any ethernet or FDDI driver must now support at least 32 simultaneous multicast addresses, with 64 recommended.

INFO: Multicast addresses in use by other active bindings.
Ndis tester will adjust list size accordingly
-- This is not an error or a warning. Real protocols such as TCP/IP use multicast addresses. Any addresses these protocols use are not available for the ndis tester to use.

INFO: List size greater than 256. Only 256 will be tested
-- This is not an error or a warning. The ndis tester currently will not handle testing more than 256 simultaneous multicast addresses. Very few cards/drivers support this many, so this should not be a major issue.

FAILURE: unable to add multicast address
-- This can happen if the driver doesn't really support as many multicast addresses as it claims, if the earlier querystats for the total number in use by other protocols returned an incorrect value, or if a protocol claimed an additional multicast address between the time the script started and this point. The last is very unlikely.

FAILURE: no packets should have been received or resent
-- Packets were received on a multicast address that was not active. Something may be going wrong in removing multicast addresses

FAILURE: should have received xx packets
-- If actually received 0 packets, this would indicate that a multicast address that was supposed to be active really wasn't. 

2c_slook.tst

This script tests that the number of bytes indicated to the tester in the lookahead buffer is actually at least as large as that requested. It does this by sending packets with up to the appropriate size, and making sure that the lookahead is the expected size. For Ndis4.0 style receives, it makes sure that the first buffer contains the required number of bytes. This test will be run in both Ndis3.0 and Ndis4.0 mode if a driver supports receive packet indications. A modified stress test is run as part of this script -- see Lan Stress Scripts below for comments related to stress tests. 

2c_spack.tst

This script tests the handling of NdisSendPackets by ndis.sys. If your driver actually supports SendPackets, you should see arrays of packets of the appropriate size handled to your driver during this test. This script is only run for miniport drivers. 

2c_srecv.tst

This script tests that the card is able to correctly receive packets with different addressing types that are actually sent across the wire (ie, that are NOT loopback packets). If the driver being tested supports Ndis4.0 style receives (ie, receive packet indications), then this script will be run twice. First, it will be run with the tester as a Ndis3.0 style protocol , and then as a Ndis4.0 protocol.

2c_srbrd.tst, 2c_srdir.tst, 2c_srfun.tst, 2c_srgrp.tst, 2c_srmul.tst, 2c_srpro.tst

These scripts are only run for full MAC drivers. They test the ability to receive packets of various address types with various filters. For miniport drivers, they are replaced with 2c_recv.tst.

2c_srque.tst

This script tests that queueing of packets for later analysis, along with the driver's handling of NdisReturnPackets. The script tests single, double, and triple queueing of the packets. It is only run for drivers that support Ndis4.0 style receive packet indications. It uses a modified stress test -- see Lan Stress Scripts below for stress test details. Unfortunately, the most common error hit by this script is often the most difficult to analyze. If the driver is not dealing with packet ownership correctly, it is very likely to bugcheck during this script. Data corruption is also a likely result of a packet ownership problem. 

2c_srrbr.tst, 2c_srrdi.tst, 2c_srrfu.tst, 2c_srrgr.tst, 2c_srrmu.tst

These scripts do further testing of send and receive by having the card that receives the packets resend them to a (usually different) address. Only the original packets are resent, so this does not result in an infinite number of packets being sent. In fact, the maximum number of packets received by each card is three times the original number. The most common problem seen with this test is dropped packets. Note that, of these 5 scripts, 2c_srrdi.tst is run in both Ndis3.0 and Ndis4.0 mode. The others are run only in the native mode for the driver.

2c_stran.tst

This script tests the TransferData function, which may be part of the driver or (for most miniports), part of ndis.sys itself. The receive path is forced to call NdisTransferData, with the starting point for the transfer set a random points within the packet. It is run in both Ndis3.0 and Ndis4.0 receive mode. A modified stress test is run as a part of this script -- see Lan Stress Scripts below for information about stress tests. 

2m_addre.tst

This scripts tests the ability of NDIS and the driver to override the adapter's current MAC address by writing a new address into the driver's registry with registry value NetworkAddress. The driver should receive the new address when it calls NdisReadNetworkAddress during initialization. 

2m_ckslg.tst

This script verifies the ability of the network card to compute checksum (tcp/ip) and segment a tcp packet. The combinations tested upon include tcp/ip/tcp-ip checksum with(out) tcp options and with(out) ip options. Also, with increasing packet size, the card will be forced to increase the number of segments since the MSS is kept a constant. 

2m_cksum.tst

This script verifies the ability of the network card to calculate and verify checksum on various combinations (tcp/udp/ip checksum with/out ip options). All combinations are tested with the encapsulation type set to 
-- Encapsulation type corresponding to the media type
-- Unspecified and the encapsulation header size set to the size of the media header
Packets are sent with correct as well as incorrect checksum to verify the correctness of the card's checksum verification mechanism. 

Problems specific to task offload scripts are :

FAILURE : Unable to set to NO task offload, This might affect the results of the variations that follow !!!
-- The set request on OID_TCP_TASK_OFFLOAD with no tasks to offload failed

FAILURE: Unable to query OID_TCP_TASK_OFFLOAD
-- There was a problem in the query to OID_TCP_TASK_OFFLOAD. The miniport is expected to handle the OID queries gracefully irrespective of its support for the OID.

FAILURE : Inconsistent task-offload information returned by miniport
-- This message is logged when the miniport does NOT return the same information for slightly different in query format but similiar in meaning queries.
-- Sample queries include
--
-- Querying Checksum Offload capability with FixedHeaderSize flag reset & invalid Encapsulation Header Size (in NDIS_ENCAPSULATION_FORMAT structure)
--
-- Querying Checksum Offload capability with Unspecified Encapsulation type & specified Encapsulation Header Size (in NDIS_ENCAPSULATION_FORMAT structure)

FAILURE : Unable to set to offload tasks
-- There was a problem in the set request to OID_TCP_TASK_OFFLOAD

FAILURE : Cannot start IP capture at Server
FAILURE : Cannot start IP capture at Test Card
-- This usually means that the client has lost connection with the server

FAILURE : Checksum Verification (by tester) passed, Checksum computed by Test NIC when it is not supposed to !!! 
-- This means that the checksum was computed by the card at the sending end when it was NOT supposed to.

FAILURE : Checksum Verification (by tester) failed, Incorrect or No checksum computation by Test Card !!!
-- This means that the card at the sending end had not or wrongly calculated checksum on the packet it sent.

FAILURE: Test NIC sends more TCP data than actually off-loaded to segment
-- The test card/miniport capable of TCP LargeSend offload fills in a value in NDIS_PER_PACKET_INFO_FROM_PACKET(Packet, TcpLargeSendPacketInfo) for the bytes sent, which is larger than the size of the packet sent from ndis. 

Debugger logs specific to task offload tests are :

lNdtVerifyAndFormatOffloadInfo: Invalid Information returned in Query to OID_TCP_TASK_OFFLOAD
Total number of bytes to be read : xxxx is less than the size of NDIS_TASK_OFFLOAD_HEADER : xxxx

-- This means that the size of the data returned in query to OID_TCP_TASK_OFFLOAD is too less to be useful. In this case, it is even less than the sizeof(NDIS_TASK_OFFLOAD_HEADER), the structure, with which the return data begins

lNdtVerifyAndFormatOffloadInfo: Invalid Information returned in Query to OID_TCP_TASK_OFFLOAD
Offset to start of next task : xxxx is less than end of current-task/offload-header

lNdtVerifyAndFormatOffloadInfo: Invalid Information returned in Query to OID_TCP_TASK_OFFLOAD
Offset to start of next task : xxxx is larger than total number of bytes to be read

lNdtVerifyAndFormatOffloadInfo: Invalid Information returned in Query to OID_TCP_TASK_OFFLOAD
Length of next task : xxxx is less than sizeof(NDIS_TASK_OFFLOAD) 

-- These errors indicate that OffsetFirstTask (a field in NDIS_TASK_OFFLOAD_HEADER) or OffsetNextTask (a field in NDIS_TASK_OFFLOAD) is filled incorrectly

lNdtCheckReceiveIpPacket: Invalid bit setting for Receive side checksum, Succeeded AND Failed bits are set

-- This error indicates that both of Succeeded and Failed bits (fields in Receive structure of NDIS_TCP_IP_CHECKSUM_PACKET_INFO structure) of at least one of tcp/udp/ip checksum are set

2m_dlock.tst

This script verifies the ability of NDIS to withstand potential deadlock situations such as receiving a request from the protocol above during data indication to the same. In this case, a request to set a multicast address is sent down to NDIS during data indication. This is an ethernet specific script.

2m_hiber.tst

This script checks to see if a driver can handle a hibernation and wakeup correctly. This test is only done on Windows NT 5.0 It can be performed on non-ACPI machines, although using an ACPI machine is recommended. After the machine wakes up, the test checks that the card is actually functional, by trying to send and receive data over it. Problems seen with this script include:

WARNING: woke too soon
-- This usually indicates that the user pressed the power switch to wake up the machine rather than letting it wake up on its own (by the timer). Note that you should never see this on non-acpi machines since they don't have a wake up timer, and you need to power cycle the machine to wake it up.

WARNING: possible wakeup problem
-- This indicates that the machine took longer to wake up than normal. This may be due to certain devices causing the process to take longer than the script expects. It may also be due to a failure of the machine to wake up on its own at all.

BLOCKED: unable to open test card
-- This usually means that something went wrong with re-initializing the netcard/driver. Check the debugger to see if you can tell anything from the output there.

2m_lgsnd.tst

This script verifies the ability of the network card to segment large tcp packets. The two combinations that it is tested with are
* Increasing number of segments with a constant MSS
* Increasing MSS with a constant number of segments
Both combinations are tested with the encapsulation type set to 
* Encapsulation type corresponding to the media type
* Unspecified and the encapsulation header size set to the size of the media header

2m_load.tst

This script tests the ability to unload and reload (stop and start) the netcard driver. This test is currently only supported for Windows NT5. It calls the configuration manager to do the unload and load, which should exercise the same code paths as enabling/disabling the device through the device manager. After reloading the driver, it checks to make sure the reload was successful by sending and receiving data on the card. Errors on this test usually mean that the card was unable to reload properly. If you see an error dealing with a call to remove the node not supported, it means that the version of the tester you are using is not matched with that of the system. Shortly before WinNT5.0 beta2 was shipped, a change was made in the configuration manager that necessitated a change in the ndis tester. The older version of the tester will not be able to do an unload under beta2 -- you will need to update your ndis tester if you see this problem.

2m_media.tst

This script checks to see that your card and driver handles media disconnect and connect correctly. It requires manual intervention. You will be prompted at least two times to unplug your media, then you will be prompted to plug it back in. It also checks that the card can send and receive data after being re-connected to the media. There are three separate tests that are done. The first checks to make sure that short duration disconnects are dealt with properly. The second makes sure that longer-duration disconnects are also dealt with properly. (Ndis.sys will attempt to put the card/driver in a low-power state if it is disconnected from the media more than about 30 seconds. For cards that support power management, this means that a different code path will be exercised with a long-duration disconnect. A third test is performed under Windows NT 5.0. In this test, the driver is unloaded after the disconnect, then is re-loaded before the reconnect. This hits yet a third code path through ndis.sys. Receive failures in this script indicate that something may be wrong with the reconnect. Problems specific to this script are:

FAILURE: no disconnect indication received
-- The tester did not receive an NDIS_STATUS_MEDIA_DISCONNECT indication from the driver (through ndis). The driver is required to call NdisMIndicateStatus with this status on a disconnect event. This error will also be seen if the user doesn't actually disconnect the media when running this test.

FAILURE: Unable to query media connect status
-- This failure means that the query of OID_GEN_MEDIA_CONNECT_STATUS failed, usually because it is not supported by the driver. This OID is required for PC98.

FAILURE: Invalid media status returned from driver.
-- This failure means that the driver did not return the expected status in the query to OID_GEN_MEDIA_CONNECT_STATUS. This may be because the driver doesn't support media connect sensing, or it is just being reported incorrectly. Or, the user may not have actually
disconnected (or reconnected) the media.

FAILURE: No connect indication received.
-- Similar to the disconnect error above, except that the expected indication is NDIS_STATUS_MEDIA_CONNECT. This can happen if the user does not actually reconnect the media OR if the user never disconnected it in the first place. Otherwise, it means the driver is not detecting a connect event properly.

2m_misc.tst
This scripts verifies the ability of the miniport to respond correctly to certain incorrect & unusual queries/set requests to OID_TCP_TASK_OFFLOAD
Sample incorrect requests include :
* Testing request of offload capability not sought during registration
* Testing TCP LargeSend Offload with a larger than allowed maximum offload size
* Testing TCP LargeSend Offload with a smaller than allowed maximum offload size

2m_prior.tst

This script verifies the card's ability to send packets with the right 802.1p priority tag as required by the protocol. The server card is trusted to correctly parse and hand over the 802.1p tag from the received packet to NDIS. Common errors reported in the log file are :

FAIL! No packets were received with correct Priority!!
-- This usually means that the test card did not attach the 802.1p tag to any of the packets sent. The other possibility being that the test card attached the wrong priority tag to all of its packets

Packets Received with Wrong Priority = xxxx
-- This usually means that some of the packets were sent by the test card with the wrong 802.1p priority tag

Packets Received with Wrong Priority Type = xxxx
-- This usually means that packets were sent by the test card with the wrong priority tag type (802.1P being the expected type).

Packets received with Non-Zero priority set is lower than the acceptable minimum of xxxx
-- This usually means one of the following
-- 1. The test was run with a 802.1p capable switch in between the test and server cards and the switch has dropped some of the lower priority packets. 
-- 2. The test card failed to attach the 802.1p tag to some of the packets that it had sent

2m_srecv.tst

This script tests receiving of packets with different address types and different filter settings. Other than the fact that the packets are sent from a different machine (instead of another card on the same machine), it is the same as 2c_srecv.tst.

2m_srbrd.tst, 2m_srdir.tst, 2m_srfun.tst, 2m_srgrp.tst, 2m_srmul.tst, 2m_srpro.tst

These scripts are the same as their 2c_xxxx version except that the packets are sent from a card on a separate machine. Like their 2c_xxx counterparts, these scripts are only run for full MAC drivers.

2m_srrbr.tst, 2m_srrdi.tst, 2m_srrfu.tst, 2m_srrgr.tst, 2m_srrmu.tst

These scripts are the same as their 2c_xxxx version except that the packets are sent from a card on a separate machine. With the single exception of 2m_srrdi, these scripts are only run for full MAC drivers.

2m_stndb.tst

This script tests the cards ability to sleep and wake up from a standby state. Depending on the machine, this may be anywhere from S1 to S3. This test is performed under Windows NT 5.0 and Windows 98 with an acpi machine. After the machine wakes up, send/receive tests are performed to make sure that the card/driver really woke up correctly. The warnings and errors are basically the same as for 2m_hiber.tst.

WARNING: woke up too soon
-- Similar to that for 2m_hiber above. If the card being tested supports wake-on-lan, it is possible that it received a wake-up packet from someone on the net.

2m_wollk.tst

This script tests the ability of the netcard to wake up the machine if it is connected to the net while sleeping. This test is only run with wake-on-lan capable netcards on an acpi machine under Windows NT 5.0 and Windows 98. The user is prompted to disconnect the card, then told to reconnect after the machine has gone to sleep. Send/receive tests are then performed to make sure the card has really woken up correctly. Problems are the same as above.

2m_wolmp.tst

This script tests the ability of the netcard to wake up the machine on receipt of a "magic packet". This test is only performed if the card is capable of this type of wakeup, and then only on an acpi machine under Windows NT 5.0 and Windows 98. Send/receive tests are done to verify that everything woke up ok. Most problems are the same as above. Problems unique to this script are:

FAILURE: MagicPacket did not wake up machine
-- This error indicates that the machine was woken up by the timer rather than by the magic packet. That would seem to indicate that magic packet wakeups do not work for the driver being tested.

2m_wolpt.tst

This script tests the ability of the netcard to wake up the machine on receipt of a packet that matches a pattern which has been given to the driver. This test is only performed if the card is supposed to be capable of this type of wakeup, and only on an acpi machine with Windows NT 5.0 and Windows 98. Send/receive tests are then done to verify that the card did wake up correctly. Most problems are the same as those listed above. Those problems unique to this script are:

FAILURE: Pattern Match did not wake up machine
-- This error indicates that the machine was woken up by the timer rather than by receiving a packet that matched the pattern. That usually means that pattern match wakeups are not working correctly, or that the pattern used was not registered properly.

FAILURE: Add/removewakepattern failed: NdisStatus = xxxxx
-- For some reason or other, the request to set the wake up pattern failed. Possibly the tester exceeded the drivers limit on the number and/or complexity of wakeup patterns accepted.

LAN STRESS AND PERF SCRIPTS

1c_stres.tst, 2c_strsb.tst, 2c_strsc.tst, 2c_strss.tst,  2m_strsb.tst, 2m_strsc.tst, 2m_strss.tst

2m_pprof.tst, 2m_pblst.tst

The stress and performances tests try to push the card and driver as far as they can, hopefully without them breaking. They do this in a variety of different ways. The perf tests see how well a card does with trying to send and/or receive data at full media bandwidth. The stress tests do some other things, such as sending lots of small packets, lots of packets containing degenerate buffers. 

An important concept in the stress tests it that of the stress client and the stress server. These are not necessarily the same as the client machine and the server machine (in two machine tests)--in fact, in some scripts they are intentionally reversed. The stress client is in full control of the stress tests. Any "stress" due to packet structure affects the client only. The stress server responds to the stress client. In general, it does one of four things in response the a packet received from the client. It either (1) just counts the packet, (2) ACKs the packet with a special packet of minimal length, (3) ACKs the packet ten times, or (4) responds with a single "echo" packet, in which the data is identical to that received from the client. It also verifies the data in each packet. The stress client, in addition to sending packets to the server(s) -- yes, there can be more than one -- has to verify and count the packets received from the server(s). Some tests use windowing, where the client will hold off sending too many more packets until it gets a response from the client.

The following are the different stress tests that are run:
(1) packets for client to send have a large number of 0-length buffers; server ACKs the packets. This is run only with the client card as the stress client.
(2) packets for client to send have a large number of 1-byte buffers; server ACKs the packets. This is run only with the client card as the stress client.
(3) client sends lots of small (< 256 byte) packets, each made up of small buffers; server ACKs the packets. This is run only with the client card as the stress client.
(4) client sends packets of all sizes from its minimum (about 40 bytes) thru 500 bytes--it loops thru this 500 times. Server ACKs the packets This is run only with the client card as the stress client.
(5) client sends packets of all sizes from its minimum (about 40 bytes) to the media maximum. It loops thru this several times. The server echos the packet. This test is also run using multiple servers, and this is the stress test that is sometimes run in non-stress scripts as a means of hitting all possible packet sizes.
(6) client sends 10000 100-byte packets, server ACKs.
(7) client sends small (<256 byte) packets, server ACKs each 10 times.
(8) client sends bunch of packets, random sizes and buffers; server just verifies data and counts.
(9) client sends bunch of random sized packets with windowing OFF; server echos packets.
(10)client sends 10000 60-byte packets with windowing OFF; server echos.

There is a lot of information in the logs from the stress tests. While the ndis tester is able to fail a card for some of the more glaring problems, lesser problems can be discerned by looking at the log data. (Usually, these are performance-related problems, such as excessive data loss). You should check over the data to verify that such packet loss does not occure. If your driver supports Ndis4.0 style receives, you should check the "ReceiveHandler" and "RcvPacketHandler" fields. The information here might be useful in helping you tune how many packets you have available, and at what point to start indicating RESOURCES so that the protocol can't take ownership. You should especially look at this information for 2c_srque.log.

There are four basic performance tests that are run. For perf tests, the client card is always the client of the test as well. In the first of the perf tests, the client sends data (as fast as possible, of course) into oblivion. In the second, it sends the data to the server, which merely counts it. In the third test, the server sends the data (as fast as possible) to the client, which may either just count it or verify and count. In the final test, both client and server are sending data as fast as they can, with both counting the packets received from the other. The performance test results in the log contain information that might help you tune your driver for better performance. The data can also help warn you about possible problems -- especially if you are seeing a lot of packets being dropped, or a very high CPU usage. Most of the problems you may hit with the stress and performance tests have been discussed in the command section above. The most common error is going to be data corruption. (If you are regularly seeing data corruption, especially with the first few stress tests, you should use a sniffer to determine whether that data corruptions occures on the sending or the receiving side.)

1c_stres.tst

This script does loopback stress. It is normally only done for drivers that support their own loopback and for full MAC drivers. 

2c_strsb.tst

This script does a two-card stress test with the test card as the stress client, and both the test card and the trusted card as stress servers. This script will encounter the same ndis.sys bug as mentioned for 1c_stres.tst. Yet another nasty multiple server test is at the end of this script.

2c_strsc.tst

This script does a two-card stress test with the test card as the stress client, and the trusted card as the stress server. 

2c_strss.tst

This script does a two-card stress test with the trusted card as the stress client, and the test card as the stress server. Another nasty multiple-server test is at the end of this script.

2m_strsb.tst

This script does a two-machine stress test with the test card acting as the stress client, and with both the test card and the server machine acting as stress servers. This script will also encounter the ndis.sys bug mentioned for 1c_stres.tst.

2m_strsc.tst

This script does a two-machine stress test with the test card as the stress client, and stress server on the server machine. 

2m_strss.tst

This script does a two-machine stress test with the stress client on the server machine, and the test card acting as the stress client.

2m_pprof.tst

This script has several parts. First, it measures how well the test card can send data by sending large bursts out into oblivion. 16 different sizes of packets are used, spread evenly across the available packet sizes for that card. Then, it measure how well the test card can receive by having the server machine send packets (of these same sizes) to the client. Here, it tests each size twice -- once with the packets just being counted, and once with the data being verified. The packet counts are all calibrated so that each variation should last approximately 30 seconds (assuming the card can actually send at line rate) 

2m_pblst.tst

This script has both the test card and the server machine sending packets, with each counting the packets sent by the other. 8 different packet sizes are used, from a minimum to the maximum size supported by both cards. The counts are again calibrated so that each variation should last about 30 seconds. NOTE: This script can be used to tell you if your card is running full duplex or not. On full duplex, each cards send rate should approach the media line rate. In half duplex, the sum of the card's send rates should approach the media line rate.

ATM FUNCTIONAL SCRIPTS

1c_csend.tst, 1c_gguid.tst, 1c_ginfo.tst, 1c_gstat.tst, 1c_gtime.tst, 1c_hiber.tst, 1c_stndb.tst, 1c_load.tst, 1c_media.tst, 1c_mkcal.tst, 1c_opcvc.tst, 1c_openc.tst, 1c_opsap.tst, 1c_reset.tst, 1c_saddr.tst, 1c_sendc.tst, 1c_sendm.tst, 1c_sends.tst, 1c_setaf.tst, 1c_srcal.tst, 1c_srque.tst, 1c_srstr.tst

2c_mkcal.tst, 2c_pcall.tst, 2c_psend.tst, 2c_sendm.tst, 2c_srque.tst

2m_csend.tst, 2m_mkcal.tst, 2m_pcall.tst, 2m_psend.tst, 2m_sendm.tst, 2m_sends.tst, 2m_srque.tst,  2m_srstr.tst

The ATM scripts are used for testing ATM and ADSL drivers. The comments below look at these scripts in the approximate order in which they are called. Note that reset-related problems (which can potentially occur at any time) are discussed under 1c_reset.tst. General send failures and receive failures are discussed under 1c_sends.tst. Call related problems are discussed under 1c_mkcal.tst. A handy tool to use in addition to the ndis tester is atmadm. This utility can help you diagnose problems related to making calls. It gives you statistics from the call manager.

nd_atm.tst

This is the master script for ATM and ADSL. It does not produce its own log file -- its data is written to nd_cli.log. It deals with the setup necessary to run a single ATM/ADSL script, as well as running the full test suite. There are no failures or warnings in this script, but some of the nd_xxx scripts that it calls can put them into nd_cli.log. Note that ADSL does not do any 2-card test, just the 1-card and 2-machine tests.

nd_cktrs.tst

This script is called by nd_cli.tst to determine if the test card and trusted card can talk to each other. It writes its information to nd_cli.log. Its communication test is to try and make a call between the trusted card and the test card. Any failures in this script are fatal -- the test will abort. The following popups may be seen from this script (there may be some additional information in the log for each of these):

TESTS ABORTED: Unable to open address family. Call manager may not be running.
-- This error means that either the card is not bound to the call manager, or that the call manager cannot see the switch. First check your  wiring. If that is ok, then check network connections to see if the call manager is properly bound to the card.

TESTS ABORTED: Unable to get ATM address from call manager.
-- This error means that the call manager cannot talk to the switch. Check the wiring, and make sure that the switch and the call manager are using the same communication spec (currently, UNI 3.1) TESTS ABORTED: Unable to make call between test and trusted card. This usually means that the two cards are not connected to the same switch.

nd_ginfo.tst

This script is called by nd_atm.tst to collect a bunch of information about the test card (and trusted card, if there is one) that will be needed to run other tests. Specifically, this script queries the appropriate OIDs to get the number of supported VCs, the supported service categories, the link speed, and the current address. If any of these queries fail or give and invalid value, an error will be written to nd_cli.log and the tests will be aborted. The possible errors from this script are pretty self-explanatory, as they all relate to a query failing in some way. This script logs its results in nd_cli.log.

nd_fdc1c.tst

This script is called by nd_atm.tst (or an individual script if running a single script test) to determine the number of calls that the test card can make to itself. It attempts this for up to four different call types -- low-bandwidth (bounded?) UBR, high-bandwidth UBR, low-bandwidth CBR, and high bandwidth CBR. (It only checks for CBR if the card supports CBR). The values it determines will be used in other scripts, to determine how many calls to make, etc. The log information from this script is written to that of the nd_cli.log, or the calling script if running a single script test. The most likely failure seen with this script is the following popup:

TESTS ABORTED: Unable to successfully make any calls. Tests will abort.
Check your hardware and retry.
-- Probably your card has died, although it is also possible that the switch has died. Atmadm might be able to help here. Chances are that you will need to reboot your system.

nd_fdc2c.tst

This script is called by nd_atm.tst (or an individual script if running a single script test) to determine the number of calls that the test card can make to the trusted card. It is basically the same as nd_fdc1c.tst except that two cards are involved. If it is unable to make any calls, the 2 card scripts will be skipped, but there is no popup. The logs are written to nd_cli.log, or the calling script if this is a single-script test.

nd_grinf.tst

This script is called by nd_atm.tst prior to running any two machine tests. It is the equivalent of nd_ginfo.tst, except it is just getting information from the server card. Data from this script is written to nd_cli.log. Any warnings or errors that occur are self-explanatory, and usually involved a query failure.

nd_fdc2m.tst

This script is called by nd_atm.tst (or an individual script if running a single script test) to determine the number of calls that the test card can make to the server card. It is basically the same as nd_fdc2c.tst except that the two cards involved are on separate machines. If it is unable to make any calls, the 2 machine scripts will be skipped, but there is no popup. The logs are written to nd_cli.log, or the calling script if this is a single-script test.

1c_csend.tst

This script is the same as 1c_sends.tst except that it runs the tests over a CBR connection. It uses the normal send/receive error messages.

1c_gguid.tst

This script tests the querying of driver information using WMI. In general, this script is testing ndis.sys and WMI rather than your driver. If your driver exports any private GUIDs to WMI, then you need to look at the last few variations to make sure your driver is handling these correctly. The test uses a QueryGlobalStatistics call with OID_GEN_CO_SUPPORTED_GUIDS to get the list of private GUIDs exported by your driver. It then attempts to query these GUIDs using WMI. The tester will report an error if the WMI query fails. If it succeeds, you need to look at the results to make sure it worked correctly.

There were several errors in WMI queries in Win98 golden. When running this test under Win98, for each query you will see the message:

WARNING: bytes needed not set correctly.

This is because of an error in Win98 when calling WMI with a NULL buffer -- it incorrectly calculated the number of bytes actually needed to store the response.

1c_ginfo.tst

This script performs a series of NdisRequest calls to the driver, to verify that it supports the querying of all required information OIDS, and that any optional OIDS that it claims to support it actually does. As with 1c_gstat.tst, you need to verify by inspection that the values returned for the various OIDS are correct. Especially look at the value returns for OID_GEN_CO_VENDOR_DESCRIPTION, as it is very common to see badly formed strings returned as a result of this query. The most common errors in this script are:

FAILURE: required oid "OID_NAME" not found in supported list.
-- Either your driver does not support a required OID, or you forgot to add this OID to your supported list. 

FAILURE: unable to query "OID_NAME"
-- The driver claimed to support an OID but the query failed.

1c_gstat.tst

This script gets the list of OIDs supported for QueryGlobalStatistics, and proceeds to query all of them. It then proceeds to do a QueryAllGlobalStatistics. Note that the tester is unable to verify most of the values returned for the queries done in this test (especially for the true statistics). It is up to the driver writer to verify that the values being returned are correct.

The most common errors in this script are:

FAILURE: required oid "OID_NAME" not found in supported list.
-- Either your driver does not support a required OID, or you forgot to add this OID to your supported list.

FAILURE: unable to query "OID_NAME"
-- The driver claimed to support an OID but the query failed.

FAILURE: unable to query all statistics
-- If there are no other failures, this probably indicates a problem in Ndis.sys.

The most common error seen with the actual data returned is with
OID_GEN_CO_VENDOR_DESCRIPTION. Make sure that the string returned is what you expect.

1c_gtime.tst

This script verifies that the initialization time for a network card is not too long. It tests the cable disconnected case first and then the cable connected case. The common failures seen with this script are similar to the ones in 1c_media.tst.

1c_hiber.tst, 1c_stndb.tst

These two scripts test the netcards response to hibernation and standby. Since how an ATM netcard should respond to these two events is not fully determined, these scripts are currently commented out. Also, they will give you a warning if you attempt to run them. For now, at least, use at your own risk.

1c_load.tst

This script attempts to stop (unload) the netcard driver, then re-start (re-load) it. It then checks to make sure that the netcard can still make a call to itself and transfer data. This script is currently commented out in the master script. To run this script, you need to select it from the manual tests.

1c_media.tst

This script checks to see that your card and driver handles media disconnect and connect correctly. It requires manual intervention. You will be prompted to unplug your media, then you will be prompted to plug it back in. It also checks that the card can make a call, and can send and receive data after being re-connected to the media. An error that occurs while attempting to make the call usually indicates a problem with disconnecting then connecting the media. Problems specific to this script are:

FAILURE: no disconnect indication received
-- The tester did not receive an NDIS_STATUS_MEDIA_DISCONNECT indication from the driver (through ndis). The driver is required to call NdisMIndicateStatus (or NdisMCoIndicateStatus) with this status on a disconnect event. This error will also be seen if the user doesn't actually disconnect the media when running this test.

FAILURE: Unable to query media connect status
-- This failure means that the query of OID_GEN_CO_MEDIA_CONNECT_STATUS failed, usually because it is not supported by the driver. This OID is required for ATM and ADSL drivers.

FAILURE: Invalid media status returned from driver.
-- This failure means that the driver did not return the expected status in the query to OID_GEN_CO_MEDIA_CONNECT_STATUS. This may be because the driver doesn't support media connect sensing, or it is just being reported incorrectly. Or, the user may not have actually disconnected (or reconnected) the media.

FAILURE: No connect indication received.
-- Similar to the disconnect error above, except that the expected indication is NDIS_STATUS_MEDIA_CONNECT. This can happen if the user does not actually reconnect the media OR if the user never disconnected it in the first place. Otherwise, it means the driver is not detecting a connect event properly.

1c_mkcal.tst

This script tests that the card can repeatedly make as many calls to itself as was determined in the "discovery" tests in nd_fdc1c.tst. Several different types of calls are used: High bandwidth UBR, which uses the link speed as its upper bounds; Low bandwidth UBR, with an upper bound of 240KB/sec; High bandwidth CBR, with a speed of about 1MB/sec; Low bandwidth CBR, with a speed of about 10KB/sec. The CBR calls are only tested if the card supports CBR. In addition to these, it also tests unidirectional calls, where the call is High bandwidth UBR in one direction, and NO_TRAFFIC in the other.

Logging is turned off by default during much of this script, to avoid using up megabytes of disk space. The messages shown below are those that can be written to the log by this script. Note that several of there are common to all scripts that make calls, so they will be listed only here.

FAILURE: cannot make any calls
-- Indicates that the discovery script was not able to successfully make any calls. Thus, the current script will be skipped.

FAILURE: unable to open Address Family
-- This message usually indicates that there are call manager problems. This may be a failure to load properly, or an error in the binding of the call manager to the driver.

FAILURE: Unable to get local ATM address!
-- Indicates that the call manager was not able to connect to the switch.

FAILURE: Unable to create SAP
-- This message usually indicates that the tester has exhausted all SAPs that are available to it. Because of the "simplified" SAPs used by the tester, only 256 simultaneous SAPs may be waiting for a call.

FAILURE: unable to create VC
-- This message usually indicates that the system is low on resources, as that is one of the few reasons for being unable to create a VC. (This could be the tester using up memory resources, or the netcard driver having already created as many VCs as it supports).

Unable to complete call to Id xxx
Retrying...
-- The makecall failed. In this script, the tester will try up the makecall up to 5 times before it gives up with a failure.

FAILURE: unable to complete call in 5 attempts
-- The makecall failed 5 separate times. The debugger should show why the makecall was failing.

1c_opcvc.tst

This script tests to make sure that the driver can create and delete a VC multiple times, and that it can create up to the number it claims to support (this number is actually adjusted down to account for the call manager, AtmLane, etc). It determines experimentally how many it can actually create simultaneously, then tries several times to create and delete this many again. The messages to watch out for in this script are:

FAILURE: Unable to open Address Family
-- this is probably due to the call manager not being able to see the switch.

FAILURE: Unable to create VC
-- something went wrong trying to create a new VC. There should also be a message in the debugger about this.

FAILURE: Unable to close test card
-- this usually means that something went wrong in cleanup--ie, not all resources were properly released when the VCs were deleted.

FAILURE: Only created xx VCs out of yy.
-- Experimentally determined that we could create yy VCs. When try to repeatedly create and delete this many, we failed. Check to see if some resources are not being released correctly.

1c_openc.tst

This script verifies the ability to open and close an adapter multiple times. Actually, miniport drivers are opened once (by ndis.sys), so this script really is testing ndis, not the driver. Any failure in this script is probably an error in ndis and needs to be reported. 

1c_opsap.tst

This script tests to make sure that the driver can open and close a SAP multiple times, and that it can open up to 256 simultaneous SAPs. The messages to watch out for in this script are:

FAILURE: Unable to open Address Family
-- this is probably due to the call manager not being able to see the switch.

FAILURE: Unable to open SAP
-- something went wrong trying to open a new SAP. Check to see if this is resource-related.

FAILURE: Unable to close test card
-- this usually means that something went wrong in cleanup--ie, not all resources were properly released when the SAPs were closed.

1c_reset.tst

This script calls NdisReset multiple times while a send test is in progress, in order to verify that the netcard driver handles resets properly. There are no log messages unique to this log. In general, if this script completes without bugchecking or hitting a breakpoint, it is usually a pass.

1c_saddr.tst

This script attempts to create and delete several alias addresses for the netcard. This is mostly a test of the call manager and the switch itself rather than of the netcard driver. The following log messages may be seen with this script:

FAILURE: Unable to get ATM address list for Open Instance
-- Indicates tester was unable to get any ATM address list at all. Usually means that the call manager isn't connected to the switch.

FAILURE: failed reading ATM address from address list
-- Probably another call manager problem. It seems to have lost its connection with the switch.

WARNING: unable to add atm address!
-- The attempt to add an ATM address (alias) failed. Usually, this is because the switch vetoed it.

FAILURE: unable to remove address!
-- Indicates that we were not able to remove an ATM address that we had previously added. This is probably a switch or call manager problem.

1c_sendc.tst

This script tests the sending and receiving of packets over several different types of calls. Tests are done with the flowspecs in the forward and reverse direction being different. One-way calls are also tested, including trying to send over a receive-only link. Most of the messages are the common send/receive messages. The following ones is specific to this script:

FAILURE: should not have resent any packets
-- This message is seen if the netcard successfully re-sent packets over a unidirectional call that should have been receive-only.

FAILURE: should not have received any packets
-- This message is seen if the netcard received packets over a unidirectional call that should have been send-only. Note that there will be another error (logged by the send command) regarding
the sends completing successfully.

1c_sendm.tst

This script attempts to send packets over up to 16 high-bandwidth UBR calls simultaneously. Relatively small number of small packets (256 bytes) are used in this test. Expect to see the normal send/receive messages in case of failures. 

1c_sends.tst

This script tests the ability to send packets over a call that the netcard has made to itself. Since all packets go over the "wire" on ATM, this isn't a simple loopback test the way it is with LAN. The packets, of various sizes, are sent over a high-bandwidth UBR call. Data is verified, and the packets may be resent. Most of the errors shown below are shared by all the send-receive tests, so they will just be given here:

FAILURE: sent xxx packets, should have sent xxx
-- Usually indicates that there were send failures. This error could also occur if the call was closed during the test, which would have aborted the sends. The reason for this failure will either be just
-- above this in the log, or on the debugger.

WARNING: received xxx packets, expected xxx
WARNING: should have resent xxx packets
-- These two messages are often paired. They indicate that packets were dropped in the send test. This is a warning if 5% or less of the packets are dropped.

FAILURE: received xxx packets, expected xxx
FAILURE: should have resent xxx packets
-- This is the same as above, except that more then 5% of the packets were dropped, so it is considered a failure.

1c_setaf.tst

This script tests the ability of ndis to "attach" the call manager to the ATM netcard driver. It is primarily a test of ndis.sys (and also the call manager). If there is a failure, it is usually due to the call manager not being able to see the switch. 

1c_srcal.tst

This script verifies the ability to make additional calls while send and receive packets on existing VCs. This test ensures the ATM netcard drivers handle the signaling and data packets properly. Most of the failures with this script are similar to the ones in 1c_mkcal.tst and 1c_sends.tst. 

1c_srque.tst

This script tests the ability of the driver to handle having the packets received on it queued for later analysis, being returned to the driver at a later point using NdisReturnPackets. It includes both some regular send/receive tests as well as a stress test that exercises most possible packet sizes. Look at the queued packets data from the send/receive and the stress tests to make sure your driver is handling the queuing correctly. The normal send/receive and stress messages are used.

1c_srstr.tst

This script first opens up to 16 calls (up to 8 CBR, if possible), and then proceeds to send large amounts of packets of various sizes over these calls simultaneously. The goal is to lose as few packets as possible. This is considered a stress test, even though it doesn't use the normal stress command. In addition to the normal send/receive messages, the following ones are associated with this script:

WARNING: lost over 50% of packets sent
-- This warning indicates that a single call lost a great deal of packets. If the same call is always losing lots of packets, it might be interesting to find out WHY that calls is losing so many.

FAILURE: lost over 10% of total packets
-- This test considers it a failure if over 10% of the total packets sent (over all the calls) are lost. This usually means that the driver is using up too much CPU, and packets are being dropped because of that. Or, some other resource (possible on the card) is limiting things.

2c_mkcal.tst

This script is the 2 card equivalent of the 1c_mkcal script. It attempts to make calls between two ATM cards on the same machine. As in the 1 card case, calls of various types are used. The messages associated with this script are the same as for 1c_mkcal.tst

2c_pcall.tst

This script attempts to set up a party call with two leafs; one on the test card and one on the trusted card. It does this in both orientations (first leaf on card making call, first leaf on other card), and tests dropping the party in both the same and inverse order. Note that there may be restriction in both the call manager and the switch regarding the number of simultaneous party calls. The messages associated with this script are:

Unable to complete party call
Retrying...
-- The tester will try to make a particular party call five times before giving up. This message is seen if one of the first four attempts fails.

FAILURE: unable to complete party call in 5 attempts
-- Even after five attempts, the call did not succeed. Check on the reason for this failure (see debugger messages). It is possible that the switch or the call manager is rejecting the call.

Unable to add party
Retrying...
-- Similarly, the tester will try up to five times to add the second leaf to the just-established party call. This message is seen if one of the first four attempts fails.

FAILURE: unable to add party in 5 attempts
-- This message is seen if the party cannot be added, even after five attempts. The reason should be indicated in the debugger.

2c_psend.tst

This script does some simple send tests over a 2-leaf party call, to verify that both parties receive the packets correctly. The problems likely to be encountered in this script are a combination of those in the normal send/receive tests, and in the 2c_pcall.tst script.

2c_sendm.tst

This script tests sending and receiving of data over multiple calls between two cards on a single machine. It is basically the same as 1c_sendm.tst, except that the two endpoints of a call are on separate netcards. Expect to see the normal send/receive messages in case of a problem.

2c_srque.tst

This script is the two-card equivalent of the 1c_srque.tst script. It tests to make sure that packet queuing works correctly, with the packets being sent from the trusted netcard. Normal send/receive log messages are used for errors.

2m_csend.tst

This script is the same as the 2m_sends.tst script, except that it runs the tests over a CBR connection instead of a UBR one. It is the two machine equivalent of the 1c_csend.tst script. Normal send/receive warning and error messages are used.

2m_mkcal.tst

This script is similar to the 1c_mkcal.tst and 2c_mkcal.tst scripts, except that the two cards participating in the test are the test card and the server card (which is on a different machine). Note that the two machine scripts should work even if the server card is connected to a different switch than the test card; as long as the two switches can talk to each other, at least. The error messages are the same as for the other two scripts.

2m_pcall.tst

This script is basically the same as the 2c_pcall.tst script, except that the second card is on the server machine. The possible errors and warnings are the same as for the other script.

2m_psend.tst

This script is the two machine equivalent of the 2c_psend.tst script. It verifies that both leafs (which are on separate machines this time) receive all packets that are sent over the party call. The possible warnings and errors are the same as for that script.

2m_sendm.tst

This script sends a relatively small number of small packets over several calls (up to 32) simultaneously. It is the two machine equivalent of the 1c_sendm.tst and 2c_sendm.tst scripts. Note that some of the calls originate on each machine, so that the packets are going in both directions during this test. The errors and warnings are the same as for the two similar scripts.

2m_sends.tst

This script tests the sending and receiving of packets over a single call between the client and the server cards. Except for using two cards on two separate machines, it is the same as 1c_sends.tst. The possible errors and warnings are the same as for that script.

2m_srque.tst

This script is the two machine equivalent of the 1c_srque.tst and 2c_srque.tst scripts. See those scripts for details. The errors and warnings are the normal ones for send/receive tests.

2m_srstr.tst

This script is the two machine equivalent of the 1c_srstr.tst script. It uses up to 24 simultaneous calls, with up to half being CBR. The calls (and the packets) go in both directions. The passing criteria is more stringent for this script than for 1c_srstr.tst. If any call loses more then 5% of the packets, it is a failure. Error and warnings messages are the standard ones for send/receive tests.

ATM STRESS AND PERF SCRIPTS

1c_stres.tst, 1c_cstrs.tst, 2c_stres.tst, 2c_cstrs.tst, 2m_stres.tst, 2m_cstrs.tst, 2m_pprof.tst, 2m_cprof.tst

In general, the stress and performance tests under ATM are very similar to those under LAN. Check the section "LAN STRESS AND PERF SCRIPTS" above for more information. The main difference is that under ATM, each stress client can only have one stress server. (Since communication is two-way under the stress tests, party calls don't really provide a true alternative way to do the multi-server tests). For performance test, ATM does not use a "send-to-oblivion" test--instead it uses a send-to-server test. Also, the performance tests can be used to verify (within limits) if the flow spec is being observed, especially for CBR calls.

1c_stres.tst

This script runs the stress tests over a call from the test card to itself. A high-bandwidth UBR call is used. This is the only stress script that runs all ten of the forms of stress described under the LAN stress section. Most other stress scripts run just 3-5 of them (with emphasis on the variations that send all sizes of data). In addition to the common call error messages, the following one is used for this (and other) stress scripts:

FAILURE: unable to start stress test
-- Indicates that something went wrong while trying to start the stress test. Usually there will be an earlier failure that will better describe the problem.

1c_cstrs.tst

This script is similar to the 1c_stres.tst script except that it sends over a high-bandwidth CBR call, and it only uses 5 different types of stress test. Note that some of the variations in this script can last for a LONG time. See the script itself for time estimates. This script uses the common call and stress error message.

2c_stres.tst

This script runs stress tests over a high-bandwidth UBR call between two separate cards on the same machine. Only three types of stress test are run (including the one the hits all packet sizes), but each is run twice once in each direction. This means that the test card runs each test once as the stress client and once as the stress server. The common call and stress error messages are used.

2c_cstrs.tst

This script is the same as 2c_stres.tst, except that the call used is a high-bandwidth CBR call. Note that the variation which tests all possible packet sizes can take a long time for cards that support large (64k) packet sizes. The common call and stress error messages are used.

2m_stres.tst

This script is the same as 2c_stres.tst, except that the two cards involved in the test are on separate machines. The common call and stress error messages are used.

2m_cstrs.tst

This script is the same as 2c_cstrs.tst, except that the two cards involved in the test are on separate machines. The common call and stress error messages are used.

2m_pprof.tst

This script runs various performance tests over a high-bandwidth UBR call between two machines. First, it runs a send test. In this test, the test card sends packets to the server machine, which just counts them. 16 different packet sizes are used, which the expected duration of each variation being about 30 seconds (assuming that the packets are actually sent at peak bandwidth). The second phase is a receive test. For this, the server machine sends the packets to the test card. Once again, 16 different packet sizes are used. Each packet size is used twice--once with the test card just counting the packets, the second time with it counting and verifying them. The final phase of this script uses a low-bandwidth UBR call to see if the card actually does traffic shaping or not. The test card sends the data to the server card. Six different packet sizes are used in this test, with the number of packets calculated so that each variation will take about 30 seconds IF the card used traffic shaping. If the card does not use traffic shaping (or if the traffic shaping does not work), the duration of these variations will be much less than 30 seconds. The normal call warnings and errors are used in this script.

2m_cprof.tst

This script tests a variety of CBR send rates to see if the card/driver is actually abiding by the CBR flowspecs (to a first approximation, at least). The number of packets is chosen so that each variation should take two minutes. 16 send rates from 50000 Bytes/sec up thru 3/4 of the full bandwidth are used in this test. The results should be inspected to determine if the card was able to use the send rate requested. Note that the requested send rate will probably be rounded by the card to the nearest supported, which means that the actual send rate may not always equal the requested rate.

WAN SCRIPTS

1c_tlcfg.tst, 1m_tlgas.tst, 1m_tlgai.tst, 1m_tlgas.tst, 1m_tlgdc.tst, 1m_tlgld.tst, 1m_tlnev.tst, 1m_tlssm.tst

2m_1perf.tst, 2m_1recv.tst, 2m_1send.tst, 2_strsc.tst, 2m_strss.tst, 2m_mperf.tst, 2m_mrecv.tst, 2m_msend.tst, 2m_strsc.tst, 2m_strss.tst, 2m_tlgci.tst, 2m_tlgcs.tst, 2m_tlsas.tst, 2m_tlscl.tst, 2m_tlsmm.tst, 2m_tscpm.tst, 2m_tsuui.tst

nd_wan.tst

This is the master script for the WAN client. Its main purposes are to get the test TAPI lines from nd_glb.tst which is dynamically created by ndtest.exe based on the selected lines, to verify the NDISWAN test card instance name, to connect to the server for 2 machine tests, launch the proper tests. Note that nd_wan.log actually contains the logs for several of the scripts that it calls. Specifically, it contains the log data from nd_ginfo.tst, nd_fdsrv.tst, and nd_1data.tst or nd_mdata.tst. So if you are trying to track down an error in nd_wan.log, the error may actually have occurred in one of those other scripts.

nd_fdsrv.tst

This script is called by nd_wan.tst on the client machine, to try and establish a connection with the server machine. If you compare this script to nd_srv.tst, you can follow the steps used in setting up the connection between the client message card and the server message card. Its log information will be in nd_wan.log.

If your client and server are unable to establish a connection, you will probably see the following message in nd_wan.log:

Timed out waiting for 1st response
-- Either there is a connection problem (i.e., cables), or the client and server machine are running different versions of the Ndis tester. Check nd_srv.log to determine which.

nd_ginfo.tst

This script is called by nd_wan.tst to collect a bunch of information about the test card that will be needed to run other tests. Specifically, this script queries the appropriate OIDs to get the maximum lookahead, the maximum total packet size, and the current address. If any of these queries fail or give and invalid value, an error will be written to nd_wan.log and the tests will be aborted. The possible errors from this script are pretty self-explanatory, as they all relate to a query failing in some way.

nd_1data.tst

This is the master script for one-call data tests. It's called by nd_wan.tst. Its purpose is to set up a call between the WAN client and server. After the call is connected, it opens the test card and it launches the 2m_1xxx test(s). The common problem is as following: 

FAILURE: The server didn't get the call this client has made.
HELP: The RAS server is probably running on the server side. Stop the RAS services.

As the help line indicates, this normally means the RAS service is active and the WAN test server doesn't have a chance to answer the calls. It's also possible that you did enter the correct calling numbers.

nd_mdata.tst

This is the master script for multiple-call data tests. It's called by nd_wan.tst. Its purpose is to set up multiple calls between the WAN client and server. After all the calls are connected, it opens the test card and it launches the 2m_mxxx test(s). The common problems are as following:

FAILURE: Timeout waiting for the call to be connected.

FAILURE: The server got only %d calls, %d expected.\n" $Value $CallCount
HELP: The RAS server is probably running on the server side. Stop the RAS services.

Like nd_1data.tst, these problems mean either the RAS service is active on the WAN test server or the calling numbers are incorrect.

nd_srv.tst

This is the master script for the WAN server. Its purpose is to start up the server work card and the server message card, and to establish communication between the client and the server. Note that the server never initiates any communication--it only responds to messages from the client. Normally you don't need to look at its log file (nd_srv.log), but it might help you if you are unable to get the client and server to connect.

1m_tlcfg.tst

This script tests lineGetDevConfig (OID_TAPI_GET_DEV_CONFIG) and lineSetDevConfig (OID_TAPI_SET_DEV_CONFIG). It verifies all the fields contain defined values and these fields don't contain conflicting information. The failures in this log file should be self-explanatory.

1m_tlgac.tst

This script tests lineGetAddressCaps (OID_TAPI_GET_ADDRESS_CAPS).

1m_tlgai.tst

This script tests lineGetAddressID (OID_TAPI_GET_ADDRESS_ID).

1m_tlgas.tst

This script tests lineGetAddressStatus (OID_TAPI_GET_ADDRESS_STATUS).

1m_tlgdc.tst

This script tests lineGetDeviceCaps (OID_TAPI_GET_DEVICE_CAPS).

1m_tlgld.tst

This script tests lineGetLineDevStatus (OID_TAPI_GET_LINE_DEV_STATUS).

1m_tlnev.tst

This script tests lineNegotiateExtVersion (OID_TAPI_NEGOTIATE_EXT_VERSION). 

1m_tlssm.tst

This script tests lineSetStatusMessages (OID_TAPI_SET_STATUS_MESSAGES).

2m_1perf.tst, 2m_mperf.tst

These two scripts do the performance profile tests with 16 different packet sizes.

2m_1recv.tst, 2m_mrecv.tst

These tests verify the ability to send, receive, and resend self-directed  packets between two different cards on different machines.

2m_1send.tst, 2m_msend.tst

These two scripts send packets from the server to the client with different packet sizes. 

2m_1strc.tst, 2m_mstrc.tst

These scripts do a two-machine stress test with the test card as the stress client, and stress server on the server machine. 

2m_1strs.tst, 2m_mstrs.tst

These two scripts do a two-machine stress test with the stress client on the server machine, and the test card acting as the stress server.

2m_tlgci.tst

This script tests lineGetCallInfo (OID_TAPI_GET_CALL_INFO). 

2m_tlgcs.tst

This script tests lineGetCallStatus (OID_TAPI_GET_CALL_STATUS).

2m_tlsas.tst

This script tests lineSetAppSpecific ( OID_TAPI_SET_APP_SPECIFIC).

2m_tlscl.tst

This script tests lineSecureCall ( OID_TAPI_SECURE_CALL). 

2m_tlsmm.tst

This script tests lineSetMediaMode ( OID_TAPI_SET_MEDIA_MODE).

2m_tscpm.tst

This script tests lineSetCallParameters (OID_TAPI_SET_CALL_PARAMS).

2m_tsuui.tst

This script tests lineSendUserUserInfo (OID_TAPI_SEND_USER_USER_INFO).

 

TDITEST Scripts

The scripts for the tdi tests follow a layout similar to that of the ndis tests.  The main directory has master scripts for the client and the server.  The client master script calls the master script for the appropriate protocol, with each protocol and its scripts existing in a separate subdirectory.  The actual test scripts are almost identical from one protocol to another—the main difference is the names and address types used, although a few of the other options may vary as well.  So the description of the test scripts below is general—ie, they are not specific to a given protocol, even if examples from a protocol are used.  Note that some of the script names my vary somewhat depending on the protocol.  Ie, what is 2m_sbudp.tst for tcpip might be 2m_sbipx for ipx/spx.

Control scripts:

td_cli.tst

This is the client master script.  It obtains information for running the tests from hapi.ini and td_glb.tst.  It establishes a connection to the server (if required), and calls the appropriate protocol master scripts to actually do the work.  It also checks for possible memory leaks by reading the memory pool usage information before and after running tests, and reporting any discrepancies—at least with the network-related tags.

 

td_srv.tst

This is the server master script.  It also obtains information for running the server from hapi.ini and td_glb.tst.  It waits for a connection request from a client, and cooperates in establishing that connection.  It then executes commands as instructed from the client.  Like the client master script, it checks for possible memory leaks by reading the memory pool usage information.

 

td_glb.tst

This script is generated by ndtest.exe.  It contains information that is necessary for running the tests, but which cannot easily be placed in and extracted from hapi.ini.  It is called by td_cli.tst and td_srv.tst as part of their initialization.

 

ipmain.tst

This is the tcpip master script.  It is called by td_cli.tst when the interface being tested exposes an IP address.  It tests the opening and closing of the control channel, as well as the support of the various queries that can be made of the control channel.  Its main task, however, is controlling the execution of the actual test scripts.

 

ipxmain.tst

This is the master script for IPX/SPX tests.  Otherwise it is identical to ipmain.tst

 

chkcall.tst

This is a helper script that checks whether it is possible for an endpoint on the client and one on the server can talk directly to each other or not.

 

Test Scripts:

 

1m_func.tst

This script tests for loopback functionality.  It verifies that address objects can be opened and closed, that events can be enabled, and that datagrams can be sent and received.  It also verifies that endpoints can be open and closed, that endpoints and address objects can be associated and disassociated, that connects can be made and disconnected, and that data can be sent and received over a connection. 

 

1m_buff.tst

This script is very similar to 1m_func.tst, except that it sends the data from user mode buffers, and it accept the data into posted user mode buffers.

 

1m_listn.tst

This script verifies that loopback connections can be accepted by listening for them as well as by using a connection handler.

 

1m_srtcp.tst

This script verifies that packets of various sizes can be sent and received over a loopback connection.  The maximum packet size used is 204800 bytes

 

1m_srudp.tst:

This script verifies that datagrams of various sizes can be sent and received using loopback.  The packet sizes used extend from about 20 bytes to the maximum datagram size supported by the protocol.

 

2m_func.tst

This script tests for functionality between two machines.  The basic tests are the same as for 1m_func.tst, except that all calls (and all data sent) is between two machines.

 

2m_buff.tst

This script is similar to 2m_func.tst, except that data is sent from a user-mode buffer and received in a posted user-mode buffer (rather than using a receive handler)

 

2m_listn.tst

This script is similar to 1m_listn.tst, except that the two endpoints are on different machines.

 

2m_osctc.tst

This script does a repeated “open connection”, “receive data”, “close connection”, which is similar to what happens when running internet explorer

 

2m_sbtcp.tst

This script maps a large block of user mode memory, then runs a receive test over a connection with the data in this memory block being used.  The actual tests first use 20 packet sizes from 20 bytes to 64K bytes, then use 10 sizes from 64K to 2560K bytes.

 

2m_sbudp.tst

This script maps a large block of user mode memory, then runs a receive test with datagrams using this memory block as a target.  The tests use 20 packets sizes from 20 bytes to the maximum datagram size supported.

 

2m_srque.tst

This script takes ownership (queues) packets received on the ChainedReceiveHandler.  This corresponds to packets indicated up via the Ndis4.0 NdisIndicateReceivedPackets mechanism.  This tests that both the protocols and the drivers deal with packet ownership correctly.

 

2m_srsml.tst

This script tests the sending of highly fragmented data both over a connection and as datagrams.

 

2m_srtcp.tst

This script is basically the same as 2m_sbtcp.tst, except that it uses the nonpaged pool rather than mapped user memory for the received data

 

2m_srudp.tst

This script is basically the same as 2m_sbudp.tst, except that it uses the nonpaged pool rather than mapped user memory for the received data

 

2m_tlstr.tst

This script stresses sending large packets over a connection, making sure all the data is received correctly.  This test sends 5000 packets of 256K bytes each.

 

2m_tstrs.tst

This script stresses sending and receiveing data over a connection.  Both side of the connection send and receive data for 15 minutes, with a random packet size of up to 128K bytes.

 

2m_ustrs.tst

This script stresses sending and receive datagrams.  Both sides send and receive datagrams for 15 minutes, with a random packet size of up to the maximum datagram size supported.

 

2m_usage.tst

This script tries to simulate heavy usage over a number of connections and datagram “pipes”.  16 potential connections are established.  The script then randomly picks one.  If it is currently closed, it opens both sides either as address objects (for datagrams), or it opens them and establishes a connection.  If the potential connection randomly picked is currently active but not sending data, the script will randomly close it, start a send test, start a receive test, or start a two-way send/receive test.  It the potential connection was currently active and had started a send  or receive test, it checks to see it is done or not.  This runs until 5000 opens have been performed.

 

 

NDISTEST PACKET STRUCTURE

This section documents the packet structure used by the ndis tester, in case you are trying to interpret a sniff or are looking at a corrupted packet. Each packet sent by the ndis tester will consist of a media header, a NDISTST protocol header, and the actual data being sent. ATM does not use a media header.

The media header used for ethernet is the 802.3 header. This consists of 6 bytes of destination address, 6 bytes of source address, and two bytes of length (high order byte first), for a total of 14 bytes.

The 802.5 token ring header consists of the AC byte (value = 0x10), the FC byte (value = 0x40), 6 bytes of destination address, and 6 bytes of source address. Once again, the total media header length is 14.

The FDDI header consists of the FC byte (value = 0x57), 6 bytes of destination address and 6 bytes of source address. The total length of the FDDI header is therefore 13 bytes.

The following is definition of the 32 bytes the currently make up the protocol header used by the ndis tester:

8 byte SNAP header: 0xAA 0xAA 0x03 0x00 0x00 0x00 0x81 0x37
4 byte tester signature: 0x4e 0x44 0x49 0x53 ('NDIS')

UCHAR packet_type: 0x00 -- normal functional test packet
0x01 -- functional test packet with information for resending the packet
0x02 -- message packet (used for commands/responses between the Client Message Card and the Server Message Card)
0x03 -- no longer used
0x04 -- performance test packets sent by client
0x05 -- no longer used
0x06 -- performance test packet sent by server
0x07 -- no longer used
0x08 -- stress test packet sent by stress client
0x09 -- full response packet sent by stress server
0x0A -- ACK packet sent by stress server
0x0B -- priority test packets
0x0C -- priority test packets

UCHAR data_start: value from 0x00 to 0xff. This indicates the value of the first byte of actual "data" in the packet
USHORT packet_size: number of bytes of data AFTER the protocol header
USHORT connect_id: used for further identification of the intended receiver (sort of an identifier for a particular open instance or VC)
USHORT command_id: For message packets, this is incremented for each command that is sent, and used to determine whether this packet contains a new command or is a retry of a previous command.
ULONG sequence_#: count of which packet this is in the current test
ULONG priority: priority value and type with which this packet is to be sent (priority tests not covered in this doc)
ULONG checksum: checksum of the preceeding bytes of the protocol header

The format of the actual data being sent varies by the packet type. Most packet types consist of a series of bytes with monotonically increasing values. The first byte of the data will be the value stored in the data_start byte of the header. This is the data type used for packets of type 0x00, 0x04, 0x06, 0x08, 0x09, and (I think) 0x0B. The data is the same for for packet type 0x01, except that 6 bytes which contain the resend information are inserted at the beginning.

Packet types 0x0A and 0x0C do not contain any data. The data for packet type 0x02 varies greatly, depending on the message being sent.

OID_GEN_PHYSICAL_MEDIUM

NDIS Miniport Driver Writers:

If your adapter is Wireless LAN, Cable Modem, Phone Line, Power Line, or xDSL, we have asked you to declare yourself as a medium type of NdisMedium802_3 or NdisMediumAtm. However, in some situations your performance/features differs from these medium. In order to be able to differentiate you from actual 802.3 and ATM adapters we are adding a new NDIS OID, which is described below.

Initially this OID will be used by the NDIS Tester to run tests differently, or to run different tests altogether for these medium. All NDIS Tester modifications for the following media will be run only if this OID is responded to appropriately. This is an optional OID and should only be supported by these medium types. It is possible that other Microsoft operating system components will use this OID in future releases.

 The only exception to this is existing ADSL drivers for which modifications have already been implemented based on the detection of differing inbound and outbound link speeds through the OID_GEN_CO_LINK_SPEED OID. Obviously, this mechanism will quit working when a different medium comes along with differing link speeds or if this is an SDSL implementation. Therefore all new xDSL drivers should implement this new OID so future versions of the NDIS Tester will not need to rely on the differing link speeds.

If you already have drivers that have been accepted by Microsoft they do not need to be changed to support this OID. However, if for any other reason your drivers are changed, please include support for this new OID.

Starting with this version of the NDIS Tester this oid will be queried.  This information is used to differentiate  DSL drivers from atm drivers.  The old method of checking for link speed differences is also still in place.  Please see scripts\atm\nd_atm.tst. 

NDIS tester version 3.76 and greater has integrated the tdi tester with normal NDIS tester so cable modem adapters can be tested.  Cable Modem drivers need to utilize this OID so the NDIS tester will automatically run the 2 machine tdi tests instead of the 2 machine lan tests.

Below is the proposed DDK documentation for the OID. Something similar to this will appear in the DDK.

 

OID_GEN_PHYSICAL_MEDIUM

This OID specifies the physical media types that the NIC supports. These media types are listed as a proper subset of the following system-defined values:

PhysicalMediumWirelessLan

The physical media is wireless LAN in nature, including but not limited to IEEE 802.11.

PhysicalMedumCableModem

The physical media is DOCSIS based cablemodem

PhysicalMedumPhoneLine

The physical media is standard phone lines e.g. HomePNA media

PhysicalMedumPowerLine

The physical media is power distribution system wiring.

PhysicalMedumDSL

The physical media is Digital Subscriber Line, which includes ADSL and UADSL (G.Lite)

 

This is intended to be a companion oid to OID_GEN_MEDIA_SUPPORTED. It is to be used by the above devices in order to differentiate them from the devices they declared themselves to be in OID_GEN_MEDIA_SUPPORTED.

This is an optional oid and should only be supported by the above devices.

Length is 4 bytes

query is optional

set is not supported

 

The  modifications to for this OID will be in ntddndis.h. You will find newoid.h in the root directory of where the NDIS Tester was installed.  You can include newoid.h  in your drivers until the you receive the updated include file in the ddk.

 

FAQS

Q: Where can I find the latest version of the tester?
A: The latest version of the tester is always available on ftp.microsoft.com/services/whql/ndis, self-extracting archive ndisbeta.exe. NOTE: always download to an empty subdirectory. After downloading, always extract with ndisbeta -d. Then you can proceed to installing the new version.

Q: One of the test scripts always fails when run as part of the full test suite, but always passes when run alone. What could cause this?
A: This is most likely a resource problem. It sounds like the tests run before the failing one use up a resource (ie, they don't free it properly). Alternatively, the previous script may have left the card in a state which is incompatible with the failing script. This shouldn't happen, because each script closes all open instances before exiting.

Q: What steps should I follow if I encounter a problem?
A: To a great degree, this depends on what kind of problem it was...
(1) If the problem is a popup while running the test which says something like "command error", click on cancel to exit the tester, and send the log file as specified below. You found a script error, and we need to fix it.(2) If the problem is a log error or warning, first see if the associated message adequately describes the problem. If not, then check this document. If neither helps, then send a copy of the log as specified below. (3) If the problem is a breakpoint within the tester, there will be a message written to the debugger just before the breakpoint is hit. That message plus the explanation in this file should be adequate. If not, you may need to set us the debugger info as indicated below. (4) If the problem was a bugcheck/crash, do a stack dump to see where the fault occurred. If the problem appears to be in the ndis tester, first check to make sure any parameters that your driver may have passed to the tester are correct. If you don't seen any problem on your end, then treat this like #3 above. If the ndis tester is nowhere on the stack, then we can't help you any. We also can't help if the ndis tester's symbols weren't loaded.

Q: What information do I need to send you for a problem, and where do I send it?
A: For all problems that weren't covered in this document, send e-mail to ndiststr@microsoft.com. Always include (1) The OS you were running on (2) the version of the ndis tester you were using (3) machine configuration information. For script errors, send the log from the offending script. For log errors or warnings, sent the offending log plus the corresponding debugger output (if possible). For breakpoints, send the context back to the beginning of the current script (if possible). If you can't get that much context, tell us what the current script was and which variation it was on. You should be able to get this information from your monitor. PLEASE (for all but script errors) try to do some investigation of your own before contacting us. In addition, you should always try to run the latest ndis tester if you encounter any problems. 

Q: How do I tell what version of the ndis tester I am running?
A: Check the about box in ndtest.exe. Or at the top of each log is a header with the version.  This is also put into the debug output.  Or every 'open' command will output the version information in the log and the debug output.

Q: How does the ndis tester force IRQ sharing ?
A: It works in the following way

1. Create a dummy (ie. virtual) device

2. Unload the Test Card

3. Make dummy device consume all free IRQs

4. Load the test card. PnP manager will not find any free IRQs to allocate to Test Card. So, it allocates an IRQ that is already allocated to another device, to the Test card, thereby forcing it to share the IRQ with the other device.

5. Unload the dummy device & free all IRQs consumed by it.

This test will run only on LAN/ATM cards and "PCI - Win 2000 - x86 - Uni Processor"  combination.

At the end of this test, you might see a few pop-ups with the title "Unsafe removal of Device" - this is by design in the OS and will get closed by itself thru a "dialogkiller" app launched by the tester.
The nd_cli.log (search for "forceirqshare") file contains the result of this test

ndtest.exe options menu

debug - enable extra output to debugger.  This is very useful when troubleshooting problems.

loop - this will cause all selected tests to be rerun continuously when they complete.

viewer... - select the viewer for log files.

Do NOT force IRQ sharing – will cause the tests to be run without forcing the test card to share IRQ. This option must not be checked for WHQL submissions.

Driver Verifier -> Ignore - totally ignores driver verifier settings. The tests just run. (Win2k only)

Driver Verifier -> Disable - totally disables driver verifier (Win2k only)

Driver Verifier -> Enable - enables all options of driver verifier except fault injection. (Win2k only)

Driver Verifier -> Enable w/fault injection - enables all options of driver verifier including fault injection.  This is not very useful because this causes the NDIS tester to fail 'open' commands.  If the NDIS tester cannot open the adapter then no tests can be run.  This will be changed in the future to use a fault injector scheme that impacts the drivers only. (Win2k only)

Use 2m TDI Tests – This is used to replace the normal 2m machine tests for ATM and lan adapters with the tdi tests.  This must be set on both the client and server.  This is only needed for Cable Modem and Frame Relay with ELAN drivers.  Cable Modem drivers that support OID_GEN_PHYSICAL_MEDIUM will not need to manually set this option.  It will be done automatically.

Reset Defaults - resets the settings for these menu options.

Use Existing Hapi.ini - for internal use only.

Launch hapi under ntsd - ntsd is the user mode debugger.  This is helpful for catching user mode bugs in hapi and ndistst.dll.  In general this is not needed.

 

History of Changes

10/22/99 Version 3.77
1) Added the tdi tester to the NDIS tester.  This enables testing from the tdi level.  This has been combined with the NDIS tester LAN/ATM by using the "Use 2m tdi Tests" option in the ndtest.exe option menu.

 

2) Added test to force IRQ sharing

The test to force a netcard to share its IRQs has been integrated with the ndis tester.

This test will run by default on the test card on the client when any of the ndis tester tests is started on the PCI card - Win 2k - x86 - Uni processor combination. Since this test takes about 2 to 3 minutes to complete, there is an option in the UI "Do NOT Force IRQ Sharing" to -not- run this test.

Two new script commands "canrunirqsharetool" & "forceirqshare"  have been introduced.

1. canrunshareirqtool - takes in the DevNode string of the netcard as the argument and determines if the IRQ sharing test can ben run on this netcard

2. forceirqshare - takes in the DevNode string of the netcard as the argument and forces IRQ sharing

Since there are load/unload tests in the ndis tester test suite that might cause the IRQs to be rearranged (& hence let the netcard to -not- share its IRQs), the "forceirqshare" command is invoked from the nd_lan(& nd_atm for atm) script after 1c_gtime, 2m_load & 2m_addre scripts are run in the ndis tester.

 

3) Modified tests for wireless lan adapters.  This requires the driver to support OID_GEN_PHYSICAL_MEDIUM.

4) Added a new command 'gentestheader' that puts more information in the gettestinfo header.  This info goes into ndistest.log.

5) Stopped timing out CloseAdapter, Open/CloseAddressFamily, Open/CloseSap, Create/DeleteVC,Make/CloseCall, and Add/DropParty.  The test now stops if these calls fail to complete.  This will make identifying the problem easier.

6) Added an assert in our unbind handler.  Our unbind handler should never be called unless there is a problem.  We always close any opens before doing anything that would cause our unbind handler to be called.

7) Allowed any device to reset while it's cable is removed.  This is needed by Token Ring and ADSL adapters.

8) Set first dword to 0 in protocol header for 1394

9) fixed 1c_load2.tst for cases where there is no trusted or message card.

10) removed 1c_openc.tst from HCT tests.

11) Added support for 'modem' call types for wan adapters.

12) removed confusing error message "CM_Enumerate_Enumerators failed: Status = %x\n"

13) Ndis.sys and ndistest.sys no longer run under driver verifier because of fault injection.

14) Changed to checking if the card reports xsum verification failure on atleast one of ip/tcp xsums.

15) Fixed problem with atm\1c_sendc that caused incorrect failures when sends should fail.

16) Changed lan\2m_srecv to use a single open and to work for wireless by reducing the throughput requirements for broadcast and multicast pkts.

17) fixed script error in 2m_addre for ndis 3 drivers.

18) Modified scripts to make sure link is established after starting the driver.

19) The OID_GEN_PHYSICAL_MEDIUM will not be queried in 1c_ginfo and 1c_gstat.  This is for multifunction devices.

20) Script name now appears in test information header when running in HCT mode.

21) Reduced the number of High Band UBR calls in atm\1c_srcal.tst because the system would run out of memory and the

    calls would fail but it wasn't obvious why.

22) Added ignore option for driver verifier.

23) Added a new test 1c_fault.  This tests injects faults while the driver is loading.

24) Added a check to make sure pci devices are run on the pci bus 1.

25) Increased delay before the server sends wakeup packet from 30 seconds to 40 in 2m_wolmp.tst and 2m_wolpt.tst

26) Added workaround for drivers that return STRUCTURETOOSMALL but don't set dwNeededSize (X.25)

27) Added more 0 and 1 byte buffers to stress tests and added a 0 len buffer at end of chain

28) removed the "warning" messages from the results log - for the 2m_tlscl and 2m_uui wan tests

29) Removed confusing log print statement (FAILURE: ...) in wan scripts.

30) Added a wake on lan test case with a 6 byte pattern

31) Added warning if there is more than 64 MEG of ram in the machine.  This may become a failure in the future.

32) Changed 2m_stndb.tst to not stop the test when the standby command fails.  In Win98 this command was failing often.

33) ndtest.exe now calls ‘SetCurrentDirectory” so it can be run from anywhere and not just from the i386 directory.

34) Removed the 2m_wollk.tst because this feature is no longer enabled by NDIS.  Changed 2m_media to not run the test where the cable is pulled and then a 45 second delay is done and then the cable is plugged back in.  This was done to test the NDIS feature that put the adapter into d3 20 seconds after the cable was pulled.  But this is not done by NDIS anymore so the test is not needed.  Win98SE NDIS will put the adapter into D3 but Millennium will not.

 

Known issues with 3.77
1. Perf tests use 450 packets.  It is possible to run out of packets which would artificially lower throughput values.  This does NOT  happen on speeds of 135 mbit and slower. (This does not cause a variation failure.)
2. There is a problem with the perf test that causes the elapsed time to be less than the actual test time.  This causes the throughput to be greater than physically possible.  (I do not think these two issues counteract each other :) (This does not cause a variation failure.)
3. Getevents will report 3 (for instance) status indications but then only list 2 status events.  Some events are not accounted for.  2m_media.(This does not cause a variation failure.)
4. We are seeing send failures during the stress tests on dma adapters using ScatterGatherDma.  (Win2k only)(This does not cause a variation failure.)
5. User mode bugcheck in 1c_guid with some adapters on some machines. (Win2k only)

6. Warnings in the following files are caused by “QoS Packet Scheduler” bug.  It is best to not run the NDIS tester with this bound to the adapter.  Disable this in the property page of the driver.  This is not bound by default.  This is in Win2k, it will not be fixed for RTM.

1c_srecv.leth                  182       90         0         92         0       0:3:2

2c_srrdi.leth3                  50        26         0         24         0      0:4:27

2c_srrdi.leth4                  50        26         0         24         0      0:5:32

2m_srrdi.leth3                 50        26         0         24         0      0:5:36

2m_srrdi.leth4                 50        26         0         24         0      0:5:36

The warnings indicate that too many packets were received.

getreceiveresults

- OpenInstanceHandle = 000929A8

Packets Received            =        300  (Sum of next two lines)

 -- Receive handler         =        300  (Test packets received - Ndis 3 driver)

 -- ReceivePacket handler   =          0  (Test packets received - Ndis 4+ driver)

Packet Receives Complete    =        302  (Ndis calls to ProtocolReceiveComplete)

Packets Resent              =        100

Packet Resends Pended       =        100

Packet Resends Completed    =        100

VARIATION WARNED

WARNING:  should have received 200 packets

7)  The 2 machine irda tests for Win98 do not work.  They have been disabled.  If you want to try to run them then edit scripts\irda\nd_irda.tst to remove the “goto endoftest” statement.  The irda protocol needs to be unloaded in Win2k.  You can do this by using the “net stop irda” command from the command line.

 

8/23/99 Version 3.63
1. Fixed problem with 2m_media in Win98. It generated an error "A device attached to the system is not functioning..."
2. Fixed nd_wan.tst bug with gettestinfo and undefined variable.
3. Fixed problem in 2m_media when query fails after 45 second delay.  This test was for an NDIS problem.
4. Fixed problem in nd_ginfo.tst that generated an improper failure related to task offload suppport.
5. small change to 2m_lgsnd.tst.

8/10/99 Version 3.62
1. Revamped getevents.  Moved logic from inside command to script files.  See getevents command for additional information on media connect and disconnect events.
2. Removed some popups from atm scripts.
3. Fixed bug with getevents in 2m_srque, 2m_hiber, 2m_stndb.
4. ndtest.exe now optionally launches hapi.exe with ntsd debugger with output directed to kernel debugger.
5. Added new command gettestinfo which outputs info to log and debugger at the start of each script.
6. Added 2m_load2.tst which does a better job of testing dynamic unloading and loading of the drivers.
7. Added driver verifier menu option to ndtest to enable fault interjection optionally. (Not a very usable funtion, as fault injection causes many 'open' commands to fail. The NDIS tester cannot function when it is unable to open (bind) the adapter.)
8. Added option to ndtest to  optionally timeout certain popups after 60 seconds.  lan\1c_gtime, 2m_media, 2m_wollk, atm\1c_gtime,1c_media.. 
9. Updated 2m_srmul.tst to test multiple open instances 
10. Updated 1c_ofldn.tst, 2m_cksum.tst, 2m_lgsnd.tst and 2m_misc.tst not to care for the number of reset events
11. Re-introduced the test for Invalid task offload version in 1c_ofldn.tst
12. Support for UNSPECIFIED_Encapsulation is made optional in tests in 2m_cksum.tst and 2m_lgsnd.tst
13. Reduced the packet size in lan\1c_reset.tst  to address test hangs when some cards consume 100% cpu doing the sends.

Known issues with 3.62
1. Perf tests use 450 packets.  It is possible to run out of packets which would artificially lower throughput values.  This does NOT  happen on speeds of 135 mbit and slower. (This does not cause a variation failure.)
2. There is a problem with the perf test that causes the elapsed time to be less than the actual test time.  This causes the throughput to be greater than physically possible.  (I do not think these two issues counteract each other :) (This does not cause a variation failure.)
3. Getevents will report 3 (for instance) status indications but then only list 2 status events.  Some events are not accounted for.  2m_media.(This does not cause a variation failure.)
4. We are seeing send failures during the stress tests on dma adapters using ScatterGatherDma.  (Win2k only)(This does not cause a variation failure.)
5. User mode bugcheck in 1c_guid with some adapters on some machines. (Win2k only)

7/2/99 Version 3.56
1. Added support for the new oid OID_GEN_PHYSICAL_MEDIUM.
2. Fixed a problem that caused a bug check when the test is stopped.
3. Changed 2m_addre.tst to not have 'break' statements outside of loops.
4. Removed some variations from 2m_cksum.tst that tested invalid situations.
5. Fixed a problem with performance tests that caused the test duration to be improperly reported.
6. Added the task offload tests to the tests that are run for HCT certification.
7. Updated task offload tests to match the latest specification.
8. Task offload test 2m_cksum.tst now forces a reset after setting offload information to test for persistence.
9. Modified task offload test 1c_ofldn.tst by removing tests for invalid situations.
10. Modified getsendresults to return/report the actual packets that the driver said it sent successfully.
11. This documentation file was added and access enabled through the help menu of ndtest.exe.
12. Changed the distribution and installation directory structure to be identical. Installation is now an xcopy.
13. Fixed a bug that caused the NDIS Tester to bug check if the driver reset unexpectedly.
14. Changed getevents to enable it to check and fail unexpected driver resets
15. Added check for promiscuous mode support. (It was removed from 3.45 at the last second).
16. Fixed a problem that was causing the WAN tests to not work on Win2k.
17. Added test duration parameter to performance tests.  This shortens the gig performance tests to a reasonable length.
16. Stopped printing Device ID lines after 50 to speed startup.
17. Fixed a problem in 2m_wollk.tst that erroneously expected connect/disconnect events.

5/25/99 Version 3.45
1. Modified popup error message in lan\nd_ck2mr.tst to include blurb about tester version incompatibilities.
2. Changed 1c_openc.tst and 2m_load.tst to test NDIS's ability to properly handle opening non-existant adapters.
3. Changed ndistest.sys to catch reuse of ndis packets by the driver before the tester has released them.
4. Improved the receive statistics messages in the log files.
5. Added pNdisPacket to debug print messages
6. Added check for NdisMStartBufferPhysicalMapping and NdisMCompleteBufferPhysicalMapping use.
7. Changed check for NdisAllocateMemoryWithTag to only be done for NDIS 5
8. Updated version information in ndtest ui - it had been missed in the last few releases
9. Added blurb for readmemorypool BLOCK failures with instruction on possible corrections
10. Added promiscous mode check for Ndis 5 drivers
11. Added check for max frame size and max total size. To catch 802.1p 4 byte adjustment calculation
12. Added -1 (don't care) for getevents about connect/disconnect status indications used in 2m_load.tst
13. Added resets in 2c_srque test to catch double indicated packets
14. Modified ndsetup.bat to copy documentation files during installation
15. Task Offloading tests are included
16. Enable 802.1p for token ring cards
17. Added support for 1394
18. Added stopsend command for 1c_reset test and revamped the test
19. Made reboot for driver verifier optional.
20. Added 2c_srcal in atm tests to test sending on vc's while opening new vc's

3/29/99:
1. Changed to retreive the size of the frame from the ethernet frame header if the size of the packet is less than or equal to 60.
2. Changes to find the net cards properly on recent builds
3. Enhancement to allow two more calls to ntoskrnl.exe due to linkage to libcntpr (ITEX ADSL driver)
4. Changed parameters on getevents call at end of 2m_wollk.tst, because of changes in code handling connect/disconnect events
5. Added 2m_addre.tst to test driver's ability to change ethernet address through NetworkAddress parameter in registry. This test only runs on NT 5 because of the need to load and unload the driver.
6. Added capability to test power management on Win98. 
This should enable 2m_stndb.tst, 2m_wollk.tst, 2m_wolpt.tst, and 2m_wolmp.tst. Also changed script files so 2m_wolpt is required for certification. The other two wake on lan tests are only required if the card claims to support it.
7. Minor fixes to generate correct hapi.ini file for wan tester
8. Minor fixes in wan tester 

2/17/99:
1. Monitoring spurious media connect/disconnect, multiple & unequal reset start/end events
2. To enable the power management test scripts to run, the tester, instead of registering as a NDIS 3.0 protocol, now, registers as a NDIS 4.0 protocol with a NULL ReceivePacket handler.
3. Auto-detection of the line ATM UNI Version & NIC's ABR capability (resulting in the UNI 4.0 & ABR specific scripts becoming a part of the general ATM test scripts)
4. Testing 802.1p : 
(i) Updated to check if a high percentage (95%) of the non-zero priority packets that were sent, are received
(ii) Changed to run as part of the HCT test suite only if support for 802.1p is indicated
5. Driver Verifier Support : Updated to turn the additional (fourth) bit "ON"
6. Fixed typos in 
ATM : 2m_sendraw.tst, 2m_promis.tst
LAN : 2m_media.tst 

1/11/99:
1. New 1c_gtime.tst : Tests the Init time of NICs
2. Updated 2m_wolpt.tst : When supported by ndis or miniport driver, 
all patterns returned in query to OID_PNP_WAKE_UP_PATTERN_LIST 
are tested for WOL. 
3. Enables "Driver verifier" on miniport driver and ndis.sys to run 
at level value 3
4. Updated valid kernel call list
5. Flag a failure if there is NO call to NdisAllocateMemoryWithTag. 
Changed from flagging a warning if there was a call to 
NdisAllocateMemory

11/17/98:
1. Support for testing 802.1p capable NICs (script : 2m_prior.tst)
2. Support for testing ATM UNI 4.0 capable NICs
Since not many NICs support UNI 4.0 yet, the test scripts (.tst)
specific to UNI 4.0 donot show up in the list (manual tests) of atm
test scripts. In order for them to show up, the test scripts in
scripts\atm\uni40 have to be copied to scripts\atm.
3. Promiscuous mode receives on ATM (script : 2m_promis.tst)
4. Sending zero length ATM packets to the miniport
(script : 2m_sendraw.tst)
5. NDIS deadlock detection (script : 2m_dlock.tst)
6. Support for querying OID_PNP_WAKE_UP_PATTERN_LIST (if the NIC
supports it) (script : 1c_ginfo.tst)
7. Testing 64 Kbps CBR ATM connections (script : 2m_voatm.tst)

8/5/98:
1) Sending less data for remote commands (especially queries)
2) Fixed bug in resetting ATM without an address family specified
3) Added check in perf test for server dead (ie, not responding). Will abort
test if server does not respond for about 5 minutes
4) Fixed perf deallocate bug (freeing packets that had never been completed)
5) PerfSend will now abort if no sends are completed for 800msec
6) Fixed reset fo NDIS_STATUS_NOT_RESETTABLE is not an error
7) Fixed successful wakeup criteria on wake-on-lan tests
8) For 2machine scripts, popup if ServerWorkCard cannot talk to test card
9) For 2card scripts, popup if TrustedCard cannot talk to test card
10) Added queryallstats to ATM getstats tests
11) Fixed series of typos in 2c_pcall script (ATM) 
12) Fixed ATM scripts 1c_hiber.tst and 1c_stndb.tst
13) Fixed close timeout problems
14) Support for testing cards with more than 256 multicast addresses.
15) load/unload now uses new api (QueryAndStopDevice)
16) Fixed SetEvent bugcheck on shutdown
17) Tester now started DEMAND rather than AUTO
18) Fix problem with running multiple instances of tester

6/11/98:
1) Added support for IrDA testing
2) Revisions to performance tests
3) Numerous error traps added (mostly dealing with bad cleanup by tester)
4) Automated power management and PnP tests
5) Script changes/additions for PC98 spec
6) Fixed problems with error handling on ATM scripts
7) Increased maximum number of simultaneous calls supported (for ATM)
8) NdisRequests will be re-tried if a reset was in progress
9) Added check to make sure client and server are running same version of
the tester
10) Added check for string length being correct to OID_GEN_VENDOR_DESCRIPTION
11) Non-HCT scripts removed from the installation tree
12) Lots of minor bug fixes