Running the IR Port Test (Winsock 1.1) (Windows CE 5.0)
The IR Port Test (Winsock 1.1) executes the tux –o –d irapi11 command line on default execution. The default command line runs the test without any connection-related test cases.
You can run the IR Port Test (Winsock 1.1) with a server. If you use IR as a control channel, you must start the server by typing irapisrv11 at the command line. You must then start the test on the client with the tux –o –d irapi11 command line.
If you use a TCP/IP network as a control channel, you must start the server by typing irapisrv11 at the command line. You must then start the test on the client with the tux –o –d irapi11 –c <server name>**command line.
Note If you choose to run the IR Port Test (Winsock 1.1) without a server, an IR device is still required on the client.
To run the IR Port Test (Winsock 1.1)
Build run-time images for the client and server devices with Infrared Data Association (IrDA) and Unimodem support.
Place the IR transmitters of the client and server devices within communications range of each other.
From <Platform Builder installation path>\Cepb\Wcetk\Ddtk\%_TGTCPU% on the development workstation, copy the Irapisrv11.exe, Kato.dll, and Tooltalk.dll files to the Windows directory on the Windows CE-based device that you want to use as the IR server device. Alternatively, if Platform Builder is connected to the Windows CE–based device that you want to use as server, copy the Irapisrv11.exe, Kato.dll, and Tooltalk.dll files to the release directory.
On the IR server device, run the Irapisrv11.exe application.
If you use a TCP/IP network as a control channel, modify the command line to pass to the test client the host name or IP address of the Windows CE–based device running Irapisrv11.exe.
In the Windows CE Test Kit window on the development workstation, right-click on IR Port Test (Winsock 1.1), and then choose Edit Command Line. Type -c <server name> at the end of the existing
tux –o –d irapi11command line.From the Windows CE Test Kit window, start the IR Port Test (Winsock 1.1).
The following table shows the test cases for the IR Port Test (Winsock 1.1).
| Test case | Description |
|---|---|
| 1: Socket create | Verifies that socket creation works for all valid parameters. This test case fails if creation of an IR socket fails. |
| 2: Socket create invalid | Verifies that socket creation fails for invalid parameters. This test case fails if creation of an IR socket succeeds with invalid parameters. |
| 3: Socket close | Verifies that the closesocket function works for an IR socket with valid parameters. This test case fails if the closesocket function call fails. |
| 4: COM port usage | Verifies that when no IR sockets are in use, the Serial Infrared (SIR) driver does not use any communications (COM) ports. The test verifies that when an IR socket exists, any attempt to open a COM port that is attached to the SIR driver fails. This test case fails if a COM port can be opened while an IR socket uses the COM port. |
| 5: Socket memory leak | Verifies that a call to the socket function and the closesocket function results in no loss of memory. The test checks the status of global memory before and after running the functions to determine if there is a memory leak. This test case always passes. |
| 6: Bind OK | Verifies that binding to a valid address succeeds. This test case fails if binding to a valid address fails. |
| 7: Bind invalid family | Verifies that binding to an invalid address family member returns an error. This test case fails if binding to an invalid address succeeds. |
| 9: Bind twice to the same socket | Attempts to bind to the same socket twice. The second bind is expected to fail. This test case fails if the first bind fails or the second bind succeeds. |
| 10: Bind same name to 2 sockets | Attempts to bind to different sockets twice using the same name. The second bind is expected to fail. This test case fails if the first bind fails or the second bind succeeds. |
| 11: Bind to a NULL socket | Attempts to bind to a NULL socket. This bind is expected to fail. This test case fails if the bind to the NULL socket succeeds. |
| 12: Bind to a NULL address | Attempts to bind to a NULL address. This bind is expected to fail. This test case fails if the bind to the NULL address succeeds. |
| 13: Bind large address | Attempts to bind the socket to various names of invalid length. This test case fails if the bind attempt succeeds. |
| 14: Bind various addresses | Attempts to bind to various valid addresses. This test case fails if the bind attempt fails. |
| 15: Bind getsockname | Verifies that the getsockname function works on a bound name. This test case fails if the getsockname function fails to retrieve names bound to the socket. |
| 16: Bind, close, bind same name | Binds a name to a socket, closes the socket, and then binds the name to the socket to confirm that the name is again available for use. This test case fails if the bind attempt fails. |
| 17: IrSIR open fail | Attempts to create an IR socket while the serial IR COM port is open. The attempt to create the socket should fail and the error should be WSAEBADF. This test case fails if the attempt to create the socket succeeds. |
| 18: Bind memory leak | Verifies that calling varying binds does not result in memory loss. This test case always succeeds. |
| 20: IRLMP_IAS_SET | Uses a simple test function that uses the IRLMP_IAS_SET socket option. This test case fails if the setsockopt function call fails with the IRLMP_IAS_SET socket option. |
| 21: Invalid IRLMP_IAS_SET | Uses a simple set of tests that attempt to use an invalid attribute type with the IRLMP_IAS_SET socket option. This test case fails if the setsockopt function call succeeds with the IRLMP_IAS_SET socket option. |
| 22: Integer IRLMP_IAS_SET | Attempts to use the setsockopt function for a variety of integer attributes. This test case fails if the setsockopt function call fails. |
| 23: Octet sequence IRLMP_IAS_SET | Attempts to use the setsockopt function for valid and invalid octet sequences. This test case fails if the setsockopt function call fails in valid cases and succeeds in invalid cases. |
| 24: User string IRLMP_IAS_SET | Attempts to use the setsockopt function for valid and invalid user strings. This test case fails if the setsockopt function call fails in valid cases and succeeds in invalid cases. |
| 25: ClassName Len IRLMP_IAS_SET | Attempts to use the setsockopt function to set a class name. This test case fails if the setsockopt function call fails. |
| 26: Attribute name Len IRLMP_IAS_SET | Attempts to use the setsockopt function to set an attribute name. This test case fails if the setsockopt function call fails. |
| 27: Attribute Count IRLMP_IAS_SET | Determines whether an object has 256 or fewer attributes. This test case fails if more than 256 attributes are allowed. |
| 28: IAS_SET memory leak | Verifies that calling various IAS_SET socket options results in no loss of memory. This test case always passes. |
| 30: Bind hard-coded LSAP-SEL | Binds a variety of Logical Service Access Point Selector (LSAP-SEL) values. This test case fails if a bind attempt fails on a valid LSAP-SEL value or succeeds on an invalid LSAP-SEL value. This test case also fails if the Object Exchange Protocol (OBEX) server is enabled. The OBEX server reserves the port required by this test case. |
| 31: Bind random LSAP-SEL | Binds null names to sockets, which causes the OS to assign a random LSAP-SEL value. This test case fails if the bind attempt fails. |
| 32: Bind same hard coded LSAP-SEL | Binds a hard-coded LSAP-SEL value to two sockets and verifies that the WSAADDRINUSE error code is returned. This test case fails if the bind attempt succeeds. |
| 42: Confirm integer IAS_SET | Performs an IRLMP_IAS_SET socket option on a valid irdaAttribInt field on a client. The test verifies, from the remote server, that the value is set correctly. This test case fails if the value returned by the query from the remote server does not match the value that was set. |
| 43: Confirm octseq IAS_SET | Performs an IRLMP_IAS_SET socket option on a valid irdaAttribOctetSeq field on a client. The test verifies, from the remote server, that the value is set correctly. This test case fails if the value returned by the query from the remote server does not match the value that was set. |
| 44: Confirm usrstr IAS_SET | Performs an IRLMP_IAS_SET socket option on a valid irdaAttribUsrStr field on a client. The test verifies, from the remote server, that the value is set correctly. This test case fails if the value returned by the query from the remote server does not match the value that was set. |
| 45: Confirm integer IAS_QUERY | Performs an IRLMP_IAS_SET socket option on a valid irdaAttribInt field on the server. The test verifies, from the remote client, that the value is set correctly. This test case fails if the value returned by the query from the remote client does not match the value that was set. |
| 46: Confirm integer IAS_QUERY | Performs an IRLMP_IAS_SET socket option on a valid irdaAttribOctetSeq field on the server. The test verifies, from the remote client, that the value is set correctly. This test case fails if the value returned by the query from the remote client does not match the value that was set. |
| 47: Confirm integer IAS_QUERY | Performs an IRLMP_IAS_SET socket option on a valid irdaAttribUsrStr field on the server. The test verifies, from the remote client, that the value is set correctly. This test case fails if the value returned by the query from the remote client does not match the value that was set. |
| 48: Confirm attrib delete | Verifies that an Information Access Service (IAS) object is deleted when the socket for the object closes. This test case fails if the IAS object is not deleted when the socket for the object closes. |
| 49: Confirm classNameLen query | Ensures that various class name lengths work correctly. This test case fails if the value returned by the remote query does not match the value that was set. |
| 50: Confirm attribNameLen query | Ensures that various attribute names and lengths work correctly. This test case fails if the value returned by the remote query does not match the value that was set. |
| 60: Bind and remote connect | Verifies that a bound socket can be connected to a remote device. This test case fails if the attempt to connect fails. |
| 61: Bind all name lengths | Binds socket names of various lengths and attempts to connect using the remote server. This test case fails if the attempt to connect fails. |
| 62: Bind all name values | Binds socket names of various lengths and attempts to connect using the remote server. The test attempts to use all legal character values in a name. This test case fails if the attempt to connect fails. |
| 63: Bind sub and super strings | The server attempts to connect to the client using names that are substrings and superstrings of the bound name. If any connections occur, this test fails. |
| 64: Bind/unbind then connect | Binds a name to a socket and then destroys the socket. The test then attempts to connect the remote side to the socket. This test case fails if the attempt to connect succeeds. |
| 65: Connect-close before accept | Verifies that performing a connect function call and a closesocket function call prior to being accepted does not cause an exception. This test case fails if the closesocket function call fails. |
| 66: Bind/connect hard coded LSAP-SEL | Attempts to bind the client using hard coded LSAP-SELs and then connect to the client from the server. This test case fails if the attempt to connect fails. |
| 70: Connect to remote bind | Remotely binds a name to a socket on the server and then connects the client to the socket. This test case fails if the attempt to connect fails. |
| 71: Connect all name lengths | The remote server binds socket names of various lengths and then the client attempts to connect. This test case fails if the attempt to connect fails. |
| 72: Connect all name values | The remote server binds various socket names and then the client attempts to connect. This test case fails if the attempt to connect fails. |
| 73: Connect sub and super strings | The client attempts to connect to the server using names that are substrings and superstrings of the bound name. If any connections occur, this test fails. |
| 74: Connect to a bad device ID | Attempts to connect to a bad device identifier. The attempt to connect is expected to fail. |
| 75: IrSir COM open fail then connect | Opens the COM port associated with the SIR driver, attempts to create an IR socket, closes the COM port, and then verifies that an IR socket can be created and connected to a remote device. The test then closes the IR socket and verifies that the COM port can be opened again. This test case fails if the COM port or IR socket cannot be opened and closed as expected. |
| 76: Connect hard-coded LSAP-SEL | The server attempts to bind using hard-coded LSAP-SELs and the client attempts to connect. This test case fails if the attempt to connect fails. |
| 78: Close connect in progress | Attempts to close a socket while simultaneously attempting to connect to a remote system. This test case fails if an exception occurs. |
| 79: Connect twice with the same socket | Attempts to connect using a socket that has failed a prior attempt to connect. This test case fails if the second attempt to connect fails. |
| 80: Enum devices disconnect and connect | Verifies that the enumeration of devices returns the same list while connected and disconnected. This test case fails if the two lists are not the same. |
| 81: Enum devices while connected | Verifies that after a remote discovery operation followed by a connect operation, a local ENUM_DEVICES returns the remote address. This test case fails if the remote address is not discovered. This test cannot be run when the control connection uses an IR link. This test is intended to test the cache of device identifiers maintained by Infrared Link Access Protocol (IrLAP). You can run this test case once on a clean system, after which the cache is filled, making subsequent runs meaningless. |
Remarks
This test library can have one or more optional command-line entries to change the behavior of the test. To specify one or more optional command-line entries to the test library, you must use the –c command-line option. This option forces Tux to pass the specified string into the test library.
See Also
Send Feedback on this topic to the authors