#ident "%Z%%M% %I% %E% SMI" mwc CDDL HEADER START The contents of this file are subject to the terms of the Common Development and Distribution License, Version 1.0 only (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] CDDL HEADER END Enterprise: Private Layer Test Specification ============================================ ABSTRACT This document describes two test specifications intended to be used in the development of test suite(s) designed to validate the private layer API described in Section 2.1 of the Enterprise DHCP Service Architecture Specification (ARCH) [1]. The first specification outlines testing requirements for the DHCP default file API (ARCH, section 2.1.1) [1]. The second specification outlines the testing requirements for the dhcptab and dhcp network container API (ARCH, section 2.1.2) [1]. Each specification contains a basic sanity test specification, designed to verify that the API works as designed when fed data in the correct form. Each specification also contains a full test specification, which compliments the basic sanity test by providing cases which test the stability and MT-safeness of the API. TEST APPLICATION Test suite(s) written to these specifications should be run on an instance of each reference platform on each build of the ON consolidation. See "Enterprise Reference Platforms" [2] for more information. 1.0 DHCP default file API Test Specification 1.1 ABSTRACT This test specification is divided into two subspecifications outlining the testing requirements for validating the default file API described in Section 2.1.1 of ARCH [1]. The first specification describes a basic sanity test, which describes the testing requirements to verify that the API works as designed when fed data in the correct form. The second specification describes a full test, which complements the basic sanity test by defining test requirements which test the error checking behavior and MT-safeness of the API. 1.2 TEST APPLICATION Test suite(s) written to this specification should be run on the reference platform of each of the supported architectures (sparcv8, sparcv9, IA32, IA64) for each build of the ON consolidation. See "Enterprise Reference Platforms" [2]. 1.3 TEST PREPARATION Prior to running a test suite, install SUNWdhcsr and SUNWdhcsu on the testing platform. No external setup is required for this test suite. Remove any existing default file, /etc/default/dhcp. 1.4 BASIC SANITY TEST Description This test validates the basic operation of the default file API function calls when presented with valid input. Test Data RESOURCE=files PATH=/var/dhcp_test RUN_MODE=server VERBOSE=TRUE RELAY_HOPS=8 INTERFACES=hme0,le0,qfe3 ETHERS_COMPAT=FALSE ICMP_VERIFY=TRUE OFFER_CACHE_TIMEOUT=11 RESCAN_INTERVAL=61 LOGGING_FACILITY=6 BOOTP_COMPAT=FALSE Case #1 write_dhcp_defaults: Use function to write the test data, using file mode of 0646. Confirm that data written matches test data. Confirm that default file created has 0646 file mode and the function returns 0. Case #2 read_dhcp_defaults: Create default file containing test data. Read data using the function. Confirm data contained with dhcp_defaults_t matches test data and the function returns 0. Case #3 delete_dhcp_defaults: Remove the default file using the function. Confirm that default file has been removed and the function returns 0. Case #4 query_dhcp_defaults: Call function, cycling through each test data key. Confirm that key is found, and that data returned is correct and the function returns 0. Case #5: free_dhcp_defaults: Using the dhcp_defaults_t built containing the test data, confirm that the function returns 0. 1.5 FULL TEST Description This test verifies that the default file API function calls respond correctly when presented with incorrect data. It also validates the MT-safeness of the API. Test Data RESOURCE=files PATH=/var/dhcp_test RUN_MODE=server VERBOSE=TRUE RELAY_HOPS=8 INTERFACES=hme0,le0,qfe3 ETHERS_COMPAT=FALSE ICMP_VERIFY=TRUE OFFER_CACHE_TIMEOUT=11 RESCAN_INTERVAL=61 LOGGING_FACILITY=6 BOOTP_COMPAT=FALSE Case #1 all API function calls: Call each of the API functions with invalid argument(s). For functions that take more than one argument, call those functions once for each argument, providing invalid data for each argument in turn. Confirm that functions return -1 and set errno to EINVAL. Case #2 existing lock file: Create /etc/default/.dhcp_defaults_lock. Confirm that read_dhcp_defaults and write_dhcp_defaults return -1 and set errno to EAGAIN. Case #2 read_dhcp_defaults: Condition Expected Result ========= =============== No default file. Confirm that the function returns -1 and sets errno to ENOENT. Default file w/ Confirm that the function mode set to 000. returns -1 and sets errno to EACCESS. Case #3 delete_dhcp_defaults: Condition Expected Result ========= =============== No default file. Confirm that the function returns -1 and sets errno to ENOENT. Default file w/ Confirm that the function mode set to 000. returns -1 and sets errno to EACCESS. Case #3 write_dhcp_defaults: Condition Expected Result ========= =============== Default file w/ Confirm that the function mode set to 000. returns -1 and sets errno to EACCESS. Case #4 Multi-access stress: Preparation: Generate TUNABLE versions of the default file containing unique combinations of defaults (no line within the TUNABLE files are the same). The default file will be written/accessed using UFS. Tunable default values: TUNABLE value: 5 INTERATE value: 100 A single multi-threaded test program can be written which can be used in the following 3 cases. It will write/read a unique version of the default file. It will retry a default file operation if EAGAIN is returned. 4.1. Multiple processes Run TUNABLE instances of the test program which writes / reads a different version of the TUNABLE default file possibilities for a tunable (INTERATE) number of iterations at once. Once the instances of the test program have completed their interations, verify that the file consists of exactly one of the TUNABLE possible versions of the default file. 4.2. Multiple threads, single process Run a single instance of the test program which creates a tunable number of threads (TUNABLE) each of which will write and read one of the unique default file combinations for a tunable (INTERATE) number of interations. Verify that after the program completes, exactly one of the TUNABLE possible versions of the default files exists. 4.3. Multiple threads, multiple processes, NFS in use Run multiple versions of the test program, each using multiple threads, some versions of the test program accessing the default directory using NFS, others using UFS. Verify after the test programs complete that exactly one of the TUNABLE possible versions of the default file exists. Caution: ensure that the number of threads * number of processes does not exceed the number of unique possible default files. 4.4. Variation of 4.1-4.3: Generate another process which periodically snags the default file lock file, and verifies that the current version of the default file matches one of the unique default file versions. 2.0 dhcptab and dhcp network container API Test Specification 2.1 ABSTRACT This test specification is divided into two subspecifications outlining the testing requirements for validating the dhcptab and dhcp network container API described in Section 2.1.2 of ARCH [1]. The first specification describes a basic sanity test, which describes the testing requirements to verify that the API works as designed when fed data in the correct form with the correct preconditions present. The second specification describes a full test, which complements the basic sanity test by defining test requirements which test the error checking behavior and MT-safeness of the API. 2.2 TEST APPLICATION Test suite(s) written to this specification should be run on the reference platform of each of the supported architectures (sparcv8, sparcv9, IA32, IA64) for each build of the ON consolidation. See "Enterprise Reference Platforms" [2]. 2.3 TEST PREPARATION Prior to running a test suite, install SUNWdhcsr and SUNWdhcsu on the testing platform. Select a public module SUNWdhc{df,db,dn} and install it. Configure any data service providing service to the public module. Set the RESOURCE and PATH default file parameters as required by the public module. Note that if the underlying public module's environment is appropriately configured, the results of testing the API should be the same for any other appropriately configured public module. The public module status can be verified by running the basic sanity test for the specific public module. The tester should record the public module environment used during the test. 2.4 BASIC SANITY TEST Description This test validates the basic operation of the dhcptab and dhcp network container API function calls when presented with valid input. Test Data Item Description Application ==== =========== =========== IP address of *_dn network. Ensure that appropriate subnet mask is available in netmasks(4). Candidate networks have to have at least 3000 hosts. dt records As follows: *_dt SrootOpt s Vendor=SUNW.Ultra-1 SUNW.i86pc,1,ASCII,1,0 SrootIP4 s Vendor=SUNW.Ultra-1 SUNW.i86pc,2,IP,1,1 SrootNM s Vendor=SUNW.Ultra-1 SUNW.i86pc,3,ASCII,1,0 SrootPTH s Vendor=SUNW.Ultra-1 SUNW.i86pc,4,ASCII,1,0 SswapIP4 s Vendor=SUNW.Ultra-1 SUNW.i86pc,5,IP,1,1 SswapPTH s Vendor=SUNW.Ultra-1 SUNW.i86pc,6,ASCII,1,0 SbootFIL s Vendor=SUNW.Ultra-1 SUNW.i86pc,7,ASCII,1,0 Stz s Vendor=SUNW.Ultra-1 SUNW.i86pc,8,ASCII,1,0 SbootRS s Vendor=SUNW.Ultra-1 SUNW.i86pc,9,NUMBER,2,1 SinstIP4 s Vendor=SUNW.Ultra-1 SUNW.i86pc,10,IP,1,1 SinstNM s Vendor=SUNW.Ultra-1 SUNW.i86pc,11,ASCII,1,0 SinstPTH s Vendor=SUNW.Ultra-1 SUNW.i86pc,12,ASCII,1,0 SsysidCF s Vendor=SUNW.Ultra-1 SUNW.i86pc,13,ASCII,1,0 SjumpsCF s Vendor=SUNW.Ultra-1 SUNW.i86pc,14,ASCII,1,0 Sterm s Vendor=SUNW.Ultra-1 SUNW.i86pc,15,ASCII,1,0 Locale m :UTCoffst=-18000: Solaris m :SrootIP4=129.148.174.27:SrootNM="atlantic": \ :SinstIP4=129.148.174.27:SinstNM="atlantic": \ :Sterm="xterm":BootSrvA=129.148.174.27: sparc m \ :SrootPTH="/export/s28/solaris1of2.s28s_wos/latest/Solaris_8/Tools/Boot": \ :SinstPTH="/export/s28/solaris1of2.s28s_wos/latest": sun4u m :Include=Solaris:Include=sparc: i86pc m :Include=Solaris:SbootFIL="/platform/i86pc/kernel/unix": \ :SinstPTH="/export/s28/solaris1of2.s28x_wos/latest": \ :SrootPTH="/export/s28/solaris1of2.s28x_wos/latest/Solaris_8/Tools/Boot": SUNW.i86pc m :Include=i86pc: SUNW.Ultra-1 m :SbootFIL="/platform/sun4u/kernel/sparcv9/unix": \ :Include=sun4u: m :Subnet=255.255.0.0:Router=172.21.0.2: \ :Broadcst=172.21.255.255: atlantic m :Include=Locale:Timeserv=129.148.174.27:LeaseTim=3600: \ :LeaseNeg:Hostname:DNSdmain="snt.east.sun.com": \ :DNSserv=172.21.0.1: 010800207E8A02 m :Impress=172.22.255.27: Dhcp network container. *_dn dn records ~3000, as follows: *_dn 00 00 +6 172.21.0.2 0 atlantic . . . 00 00 +3006 172.21.0.2 0 atlantic Case #1 dhcpsvc_errmsg: Use function in a loop to display all messages associated with the error codes in Figure 2 of ARCH [1]. Verify that messages are displayed correctly. Case #2 enumerate_dd: Verify that this function properly enumerates the public modules present on the machine under test in /usr/lib/inet/dhcp/svc. Free memory (count entries in modules). Case #3 status_dd: Verify that the selected data store service is correctly configured. Case #4 capability_dd: Verify that this function returns the correct capabilities for the public module currently configured for use. Note: Some public modules may not support this function, which will cause this function to return DSVC_UNSUPPORTED. Case #5 open_dd: Using DSVC_CREATE | DSVC_READ | DSVC_WRITE, create a dhcptab container and a dhcp network container (called ). Preserve the handles returned for later use in the following test cases. Case #6 list_dd: Verify that this function properly returns the currently available DHCP containers (Case #5) in the data service hosting the public module. Only those containers created in Case #5 should exist. Free memory (count entries in listppp). Case #7 add_dd_entry: Using the handles returned in Case #5, add the test data records to the dhcptab and dhcp network containers. Case #8 lookup_dd: 8.1. Verify case #7. Using a "count" of -1 and a "query" value set using DSVC_QINIT (Figure 5 of ARCH[1]), verify that the contents of the dhcptab container and container match the test data. "records" should equal the number of records for each container. Note that the order of the records returned may not be the same as the order in which they were added in case #7. 8.2 Verify dhcptab container type. 8.2.1. Look for all records with a DT_QTYPE value of "s". Verify that only the "s" type records are returned. 8.2.2. Look for all records with DT_QTYPE value of "m". Verify that only the "m" type records are returned. 8.2.3. Look for DT_QKEY of "atlantic". Verify that only the macro "atlantic" is returned. 8.2.4. Look for DT_QKEY of i86pc and not a DT_QTYPE of "m". Verify that only the macro "i86pc" is returned. 8.3 Verify dhcp network container type. 8.2.1. Look for all records with a DN_QCIP of +100. Verify that only one record (with a cip of +100) is returned. 8.2.2. Look for all records with DN_QMACRO value of "atlantic". Verify that all records are returned ("records" == 3000). Note that records returned may be in a different order than they were added as part of case #7. Case #9 modify_dd_entry: 9.1 Modify dhcptab container records 9.1.1 Using lookup_dd to find the record with a DT_QKEY of "Sterm", change the name of the record from "Sterm" to "sTERM". Use lookup_dd to verify that the original record has been renamed. 9.1.2 Using lookup_dd to find the record with a DT_QKEY of "Solaris", change the value portion of the record to be: :SrootIP4=129.148.174.27:SrootNM="atlantic": \ :SinstIP4=129.148.174.27:SinstNM="atlantic": \ :sTERM="sun-cmd":BootSrvA=129.148.174.27: Using lookup_dd, reexecute the lookup and verify that the value portion of the record has been modified correctly. 9.2 Modify dhcp network container records 9.2.1 Using lookup_dd to find the record with a DN_QCIP of +10, change the lease field to 1/1/2000 and the flags field to MANUAL. Use lookup_dd to verify that the original record has been changed. 9.2.2 Using lookup_dd to find the record with a DN_QFLAGS of MANUAL. Change the dn_cid field to 01080020FFFFFF, dn_flags field to MANUAL+AUTOMATIC, dn_sip field to 172.23.0.77, dn_lease field to -1, dn_macro field to "happy", and the dn_comment field to "This is a test". Use lookup_dd to verify that the original record has been changed. Case #10 delete_dd_entry: 10.1 Delete dhcptab container record Using lookup_dd to find the record with a DT_QKEY of SUNW.Ultra-1, delete this record. Verify using lookup_dd that this record can no longer be found. 10.2 Delete dhcp network container record Using lookup_dd to find the record with a DN_QCIP of +101, delete this record. Verify using lookup_dd that this record can no longer be found. Case #11 close_dd: 11.1 Close the open instance of the dhcptab container. Verify that close_dd returns DSVC_SUCCESS. 11.2 Close the open instance of the dhcp network container . Verify that close_dd returns DSVC_SUCCESS. Case #12 remove_dd: 12.1 Remove the dhcptab container. Verify that it no longer exists using list_dd. 12.2 Remove the dhcp network container . Verify that it no longer exists using list_dd. 2.5 FULL TEST Description This test verifies that the dhcptab and dhcp network container API function calls respond correctly when presented with incorrect data. It also validates the MT-safeness of the API. The test suite should allow any number of concurrent threads or test suite processes to be invoked. Test Data Item Description Application ==== =========== =========== IP address of *_dn network. Ensure that appropriate subnet mask is available in netmasks(4). Candidate networks have to have at least 3000 hosts. dt records As follows: *_dt SrootOpt s Vendor=SUNW.Ultra-1 SUNW.i86pc,1,ASCII,1,0 SrootIP4 s Vendor=SUNW.Ultra-1 SUNW.i86pc,2,IP,1,1 SrootNM s Vendor=SUNW.Ultra-1 SUNW.i86pc,3,ASCII,1,0 SrootPTH s Vendor=SUNW.Ultra-1 SUNW.i86pc,4,ASCII,1,0 SswapIP4 s Vendor=SUNW.Ultra-1 SUNW.i86pc,5,IP,1,1 SswapPTH s Vendor=SUNW.Ultra-1 SUNW.i86pc,6,ASCII,1,0 SbootFIL s Vendor=SUNW.Ultra-1 SUNW.i86pc,7,ASCII,1,0 Stz s Vendor=SUNW.Ultra-1 SUNW.i86pc,8,ASCII,1,0 SbootRS s Vendor=SUNW.Ultra-1 SUNW.i86pc,9,NUMBER,2,1 SinstIP4 s Vendor=SUNW.Ultra-1 SUNW.i86pc,10,IP,1,1 SinstNM s Vendor=SUNW.Ultra-1 SUNW.i86pc,11,ASCII,1,0 SinstPTH s Vendor=SUNW.Ultra-1 SUNW.i86pc,12,ASCII,1,0 SsysidCF s Vendor=SUNW.Ultra-1 SUNW.i86pc,13,ASCII,1,0 SjumpsCF s Vendor=SUNW.Ultra-1 SUNW.i86pc,14,ASCII,1,0 Sterm s Vendor=SUNW.Ultra-1 SUNW.i86pc,15,ASCII,1,0 Locale m :UTCoffst=-18000: Solaris m :SrootIP4=129.148.174.27:SrootNM="atlantic": \ :SinstIP4=129.148.174.27:SinstNM="atlantic": \ :Sterm="xterm":BootSrvA=129.148.174.27: sparc m \ :SrootPTH="/export/s28/solaris1of2.s28s_wos/latest/Solaris_8/Tools/Boot": \ :SinstPTH="/export/s28/solaris1of2.s28s_wos/latest": sun4u m :Include=Solaris:Include=sparc: i86pc m :Include=Solaris:SbootFIL="/platform/i86pc/kernel/unix": \ :SinstPTH="/export/s28/solaris1of2.s28x_wos/latest": \ :SrootPTH="/export/s28/solaris1of2.s28x_wos/latest/Solaris_8/Tools/Boot": SUNW.i86pc m :Include=i86pc: SUNW.Ultra-1 m :SbootFIL="/platform/sun4u/kernel/sparcv9/unix": \ :Include=sun4u: m :Subnet=255.255.0.0:Router=172.21.0.2: \ :Broadcst=172.21.255.255: atlantic m :Include=Locale:Timeserv=129.148.174.27:LeaseTim=3600: \ :LeaseNeg:Hostname:DNSdmain="snt.east.sun.com": \ :DNSserv=172.21.0.1: 010800207E8A02 m :Impress=172.22.255.27: Dhcp network container. *_dn dn records ~3000, as follows: *_dn 00 00 +6 172.21.0.2 0 atlantic . . . 00 00 +3006 172.21.0.2 0 atlantic Case #1 all API function calls: 1.1 Invalid arguments Call each of the API functions with invalid argument(s). For functions that take more than one argument, call those functions once for each argument, providing invalid data for each argument in turn. Confirm that functions return DSVC_INVAL for all cases but dhcpsvc_errmsg. This function should return a string of "unknown". 1.2 No public modules (N/A for dhcpsvc_errmsg) Call each of the API functions. Verify that DSVC_ENOENT is returned. 1.3 Permission (N/A for dhcpsvc_errmsg) Change the permission of the public module to be unreadable by any user (000). Verify that DSVC_ACCESS is returned. Restore permission of public module. Case #2 status_dd: 2.1 Supporting data service not configured. Verify that DSVC_SUCCESS is *not* returned. Some public modules may not return the same error message in this case. All should fail. 2.2 Configured data service, but unavailable. Using a data service-specific method of making the data service temporarily unavailable, call the function. DSVC_BUSY or DSVC_INTERNAL (different depending on implementation) is returned. 2.3 Configured data service, available. Verify that DSVC_SUCCESS is returned. Case #3 open_dd: Perform the following subcases once each for the dhcptab container and dhcp network container described in the test data. 3.1 No container Call function with DSVC_READ | DSVC_WRITE. Verify that DSVC_NOENT is returned. 3.2 Basic Using DSVC_CREATE | DSVC_READ | DSVC_WRITE, create a dhcptab container and a dhcp network container (called ). 3.3 NON_BLOCK Call function with DSVC_READ | DSVC_WRITE | DSVC_NONBLOCK. Depending on whether the public module supports it (see module doc), the function should return either DSVC_SUCCESS or DSVC_UNSUPPORTED. 3.4 Container exists Using DSVC_CREATE | DSVC_READ | DSVC_WRITE, verify that the function returns DSVC_EXISTS. Cleanup: Remove the containers using remove_dd. Case #4 list_dd: 4.1 No containers Verify that list_dd returns DSVC_NOENT. Case #5 add_dd_entry: Create and load containers as per Case #5 and Case #7 of the Basic Sanity Test. 5.1 Record exists Attempt to add a test data record for the dhcptab container and dhcp network container respectively. Verify that DSVC_EXISTS is returned. 5.2 Busy Close containers with close_dd. Reopen with DSVC_NONBLOCK specified. If success is returned, using a data service specific technique for making the service busy, attempt to add an additional record to each of the two containers. Verify that DSVC_BUSY is returned. Remove the busy condition, and reattempt the add. Verify that DSVC_SUCCESS is returned. close_dd the containers. 5.3 Read only Reopen the containers with DSVC_READ access only. If success is returned, attempt to add a new record to each container. Verify that DSVC_ACCESS is returned. close_dd the containers. Cleanup: Remove the containers using remove_dd. Case #5 lookup_dd: Create and load containers as per Case #5 and Case #7 of the Basic Sanity Test. 5.1. Record does not exist. Produce dhcptab container and dhcp network container queries that would not be satisfied by the test data. Verify that DSVC_SUCCESS is returned, and "records" is 0. 5.2 Busy Close containers with close_dd. Reopen with DSVC_NONBLOCK specified. If DSVC_SUCCESS is returned, using a data service specific technique for making the service busy, attempt to perform a valid lookup of records in each of the two containers. Verify that DSVC_BUSY is returned. Remove the busy condition, and reattempt the lookups. Verify that DSVC_SUCCESS is returned, and that data returned is valid. close_dd the containers. 5.3 Write only Reopen the containers with DSVC_WRITE access only. If success is returned, attempt to perform lookup_dd's using any syntactically legal query for each container type. Verify that DSVC_ACCESS is returned. close_dd the containers. Cleanup: Remove the containers using remove_dd. Case #6 modify_dd_entry: Create and load containers as per Case #5 and Case #7 of the Basic Sanity Test. 6.1 Unknown record Fabricate dn_rec_t / dt_rec_t instances known not to exist in the respective containers. Attempt to modify the records. Verify that DSVC_NOENT is returned. 6.2 Update Collision #1 Use lookup_dd to find valid dhcptab and dhcp network container records (one each). Change the signature on the resultant dt_rec_t / dn_rec_t. Attempt to modify records. Verify that DSVC_COLLISION is returned. 6.3 Update Collision #2 Use lookup_dd to find valid dhcptab and dhcp network container records (one each). Attempt to rename the records to names which already exist (dt_key + dt_type, dn_cip). Verify that DSVC_EXISTS is returned. 6.4 Busy Close containers with close_dd. Reopen with DSVC_NONBLOCK specified. If DSVC_SUCCESS is returned, acquire valid dhcptab and dhcp network container records using lookup_dd. Using a data service specific technique for making the service busy, attempt to modify the value (non-key fields) of the records. Verify that DSVC_BUSY is returned. Remove the busy condition, and reattempt the modifies. Verify that DSVC_SUCCESS is returned. Reacquire the records. Verify that the contents have been suitably updated. close_dd the containers. 6.5 Read only Reopen the containers with DSVC_READ access only. If success is returned, locate valid container records using the appropriate queries to lookup_dd. Modify the contents of a copy of the dt_rec_t / dn_rec_t. Attempt to modify the record in the containers. Verify that DSVC_ACCESS is returned. close_dd the containers. Cleanup: Remove the containers using remove_dd. Case #7 free_dd: This function should be used to release the results of lookup_dd calls. Its operation must be validated by running this test suite under bcheck with -memuse, and ensuring that no free blocks remain after exit. Note that the test suite must be written with care to make this case useful (free any allocated memory before exit). Case #8 delete_dd_entry: Create and load containers as per Case #5 and Case #7 of the Basic Sanity Test. 8.1 Unknown record Fabricate dn_rec_t / dt_rec_t instances known not to exist in the respective containers. Attempt to delete the records. Verify that DSVC_NOENT is returned. 8.2 Busy Close containers with close_dd. Reopen with DSVC_NONBLOCK specified. If DSVC_SUCCESS is returned, acquire valid dhcptab and dhcp network container records using lookup_dd. Using a data service specific technique for making the service busy, attempt to delete the records. Verify that DSVC_BUSY is returned. Remove the busy condition, and reattempt the deletes. Verify that DSVC_SUCCESS is returned. Attempt to reacquire the records. Verify that the records have been deleted. close_dd the containers. 8.3 Read only Reopen the containers with DSVC_READ access only. If success is returned, locate valid container records using the appropriate queries to lookup_dd. Attempt to delete the records in the containers. Verify that DSVC_ACCESS is returned. close_dd the containers. Cleanup: Remove the containers using remove_dd. Case #9 close_dd: 9.1 Busy Create containers as per Case #5 of the Basic Sanity Test, with the exception that DSVC_NONBLOCK is specified. If DSVC_SUCCESS is returned, using a data service specific technique for making the service busy, attempt to close the containers using the handles returned by open_dd. Verify that DSVC_BUSY is returned. Remove the busy condition, and reattempt the close_dd. Verify that DSVC_SUCCESS is returned. Cleanup: Remove the containers using remove_dd. Case #10 remove_dd: Create containers as per Case #5 of the Basic Sanity Test. 10.1 Unknown container Attempt to remove a non-existent dhcp network container. Verify that DSVC_NOENT is returned. 10.2 Busy Close containers with close_dd. Reopen with DSVC_NONBLOCK specified. If DSVC_SUCCESS is returned, using a data service specific technique for making the service busy, attempt to remove the containers. Verify that DSVC_BUSY is returned. Remove the busy condition, close_dd the containers, and reattempt the removes. Verify that DSVC_SUCCESS is returned. Verify using list_dd that the containers have been removed. Case #11 Multi-access stress The service provider layer modules underneath the private layer are not required to manage reference counts for open instances. So while individual private layer handles are considered to be MT-safe (and parallel access to data containers is suitably protected), an application using the private layer API must synchronize close and/or container remove operations among threads such that no threads hold handles to a container after the handle has been closed or the container has been removed. This case assumes a test which is multi-threaded, and can run the following test using from 1 to THREADS threads. The test can also be run in multiple concurrent processes. The goal of this test is to ensure that the API is MT-safe with respect to the containers and the records contained within those containers. This goal is accomplished by verifying that the end result of the test is consistent. Tunable default values: PROCESSES: 20 THREADS: 20 11.1 The dhcptab container test 11.1.1 open_dd Create a dhcptab using DSVC_CREATE | DSVC_READ | DSVC_WRITE. If DSVC_EXISTS is returned, retry the open attempt w/o the DSVC_CREATE flag. Log that this event occurred. Handle will be used for balance of test. If any other error occurs, terminate the test as failed. 11.1.2 add_dd_entry Add the test data records to the dhcptab container. If DSVC_EXISTS is returned, skip that record, and continue attempting to add the other records. Log that this event occurred. If any other error occurs, terminate the test as failed. 11.1.3 lookup_dd Using DT_QKEY of "atlantic" and DT_QTYPE of "m", find the atlantic record. Compare its value against the test data. If it has changed, then output a message to this affect. If any error occurs, terminate the test as failed. 11.1.4 modify_dd_entry Using the results of 11.1.3, change the record as follows. If it is no different from the test data, change the value to: :Timeserv=129.148.174.28:LeaseTim=86400: \ :Hostname:DNSdmain="east.sun.com":DNSserv=172.23.3.3: If it doesn't match the test data value, change the LeaseTim by incrementing it by one. Attempt to update the record. If it fails with DSVC_COLLISION, retry 11.1.3 and 11.1.4 for three attempts. Log message if modify was unsuccessful. If any other error occurs, terminate the test as failed. 11.1.5 delete_dd_entry Use lookup_dd to find a DT_QKEY of "SjumpsCF" and a DT_QTYPE of "s". If it does not exist, log a message. If it does exist, attempt to delete it. If DSVC_NOENT is returned, log a message. 11.1.6 close_dd Use close_dd to close the open handle. If DSVC_NOENT is returned, log a message. 11.1.7 epilogue Compare the resultant dhcptab container to the test data. The only differences should be a changed value of the atlantic macro as expected from 11.1.4 and the SjumpsCF symbol should be removed. Any other inconsistency means the test has failed. Clean up: Remove the dhcptab container. 11.2 The dhcp network container test 11.2.1 open_dd Create a dhcp network container using DSVC_CREATE | DSVC_READ | DSVC_WRITE. If DSVC_EXISTS is returned, retry the open attempt w/o the DSVC_CREATE flag. Log that this event occurred. Handle will be used for balance of test. If any other error occurs, terminate the test as failed. 11.2.2 add_dd_entry Add the test data records to the dhcp network container. If DSVC_EXISTS is returned, skip that record, and continue attempting to add the other records. Log that this event occurred. If any other error occurs, terminate the test as failed. 11.2.3 lookup_dd Find the DN_QCIP of +102 record. Compare its value against the test data. If it has changed, then output a message to this affect. If any error occurs, terminate the test as failed. 11.2.4 modify_dd_entry Using the results of 11.2.3, change the record as follows. If it is no different from the test data, change the value to: 01DEADBEEF 03 +102 172.23.3.3 941619403 Solaris If it doesn't match the test data value, change dn_lease by incrementing it by one. Attempt to update the record. If it fails with DSVC_COLLISION, retry 11.2.3 and 11.2.4 for three attempts. Log message if modify was unsuccessful. If any other error occurs, terminate the test as failed. 11.2.5 delete_dd_entry Use lookup_dd to find a DN_QCIP of +1001. If it does not exist, log a message. If it does exist, attempt to delete it. If DSVC_NOENT is returned, log a message. 11.2.6 close_dd Use close_dd to close the open handle. If DSVC_NOENT is returned, log a message. 11.2.7 epilogue The dhcp network container should be consistent at the end of a test run. The only differences should be a changed value of the +102 record with the value as per 11.2.4 and the lease time potentially incremented, as well as the +1001 record missing. Any other inconsistency means the test has failed. Cleanup: remove dhcp network container. 11.3 Multi-process run Run 11.1 and 11.2 in PROCESSES separate processes. 11.4 Multi-threaded run, single process Run 11.1 and 11.2 in THREADS separate threads within a single process. 11.5 Multi-process, Multi-threaded run Run 11.1 and 11.2 in PROCESSES separate processes each spawning THREADS separate threads. REFERENCES [1] "Enterprise DHCP Service Architecture Specification", mwc, 6/25/1999. [2] "Enterprise Reference Hardware Platforms", mwc, 10/23/1999.