This document provides detailed descriptions of the manual network controller certification tests. After you successfully complete the manual tests described in this document, use the HCTS to run the automated tests.
These Level 2 tests provide greater test coverage than the Level 1 tests. See Network Level 1 Tests and Network Level 2 Tests for further details.
When a driver supports multiple controllers, the controller that supports the most extensive feature set is designated the primary controller. Additional controllers supported by the same device driver are known as supplementary controllers.
The tests described in this document are used for one of these two purposes:
Note: The tests described in the Network Controller Certification Level 1 Test Plan are for functional testing of controllers at Level 1 or for certifying any supplementary controllers that are supported by the same driver under test as a primary controller.
These tests require two systems.
In this testing, the system under test serves data to the test manager system. In this way, the test manager system is a client of the system under test.
Make sure both systems meet the general hardware and software requirements for all certifications stated in the Hardware Certification Test Suite Installation Guide.
This section describes additional hardware and software required to execute the network controller certification tests.
This is the hardware configuration required for the test manager system.
The minimum requirements for this configuration are as follows:
This is the hardware configuration required for the system under test.
The minimum requirements for this configuration are as follows:
This is the required software configuration for both the system under test and the test manager system.
Both test machines must be configured on their own private network. They should be isolated as much as possible from any other systems. The test environment must be customized for the particular network technology being tested. Only the one network card under test should be configured. Do not configure multiple cards or logical interfaces or virtual interfaces.
HCTS supports single port NIC and multiport NIC certification. For multiport NIC, HCTS supports dual port and quad port NIC certification.
For multiport NIC certification, you must configure each port of the multiport NIC. The IP bound to each port must be in a different subnet.
If you enable IPv6 certification, you do not need to configure the IPv6 interface. HCTS automatically configures IPv6 interfaces.
Fast Ethernet
All machines are connected to a hub or switch.
When switches are used, set the ports to different speeds (for example, 10/100 Mbps or 1000 Mbps for Ethernet) and vary the transmission type (for example, full-duplex, half-duplex, or auto-negotiate).
Gigabit Ethernet
All machines are connected to a switch.
Notes:
Do not use NIS (Network Information Service). You might encounter problems if you use NIS.
Set up the IP addresses for the system under test and the test manager system in the same subnet.
Set up the IP addresses for each port on a multiport NIC in different subnets.
Both system hostnames must be resolved on both systems. On the system under test, add the test manager system hostname to the /etc/hosts file. On the test manager system, add the system under test hostname to the /etc/hosts file.
If the Solaris version is 10 or later, make sure the NFSMAPID_DOMAIN in /etc/default/nfs is set to the same domain name for both the system under test and the test manager system.
For example, to set NFSMAPID_DOMAIN to sun.com, manually edit /etc/default/nfs as follows:
Change:
#NFSMAPID_DOMAIN=domain
to:
NFSMAPID_DOMAIN=sun.com
Then do the following restart the nfsmapid daemon:
# pkill -HUP nfsmapid
These tests require two systems. Run all tests from the test manager system. The test manager system is System Configuration II. Run all tests on the system under test. The system under test is System Configuration I.
Run all tests as user root unless otherwise indicated in the HCTS test ReadMe file.
First run the set of tests for all controllers, then run the tests specific to the network technology of the controller under test.
All Controllers
Fast Ethernet
Gigabit Ethernet
[1] This test is required only if it is supported by the controller under test.
Note: For multiport NIC certification, apply the above procedures to all ports on the multiport NIC if applicable.
You only need to perform this test if you are doing one of the following:
Required Hardware
Required Software
Test Strategy
The audit_itu(1M) utility verifies the format and contents of a driver diskette created using pkg_drv(1M) or pkg_drv2patch(1M).
Test Procedure
Insert the driver diskette into the diskette drive.
Verify the driver diskette format and contents.
# volcheck
# audit_itu
Expected Results
The Pre-Boot Execution Environment (PXE) is one of the components of the open-industry specification Wired for Management (WFM) developed by Intel. This technology allows you to automate client-PC management over a network. PXE enables a system to boot from a server on a network before booting the operating system on the local hard drive.
This test verifies that the Solaris Operating System can be installed through a network using the PXE technology.
Required Hardware
Installation server with the appropriate Solaris Operating System release installed
Client to install the Solaris Operating System with a PXE-enabled BIOS and PXE-enabled NIC
Functional network connection between client and server
Test Strategy
This test involves:
Test Procedure
In this procedure, the examples shown are for Solaris 9. Replace steps as appropriate for your Solaris release.
Before beginning this procedure, you must have the following information.
In addition, you must have already set up the /etc/netmasks properly.
Note: In this test procedure, the DHCP server and installation server is set up on one machine. The hostname is server1, the IP address is 10.13.22.100, and the netmask is 255.255.255.0.
Set Up the Installation Server
Create an empty directory on the installation server.
# mkdir /export/install/ia_9
Copy the Solaris Operating System into this directory according to the Solaris installation instructions.
Set Up the DHCP Server
Configure the DHCP server.
# /usr/sbin/dhcpconfig -D -r SUNWbinfiles -p /var/dhcp
Add a DHCP network.
# /usr/sbin/dhcpconfig -N 10.13.22.100 -m 255.255.255.0
Add addresses to the DHCP service.
Multiple addresses can be added with pntadm as necessary.
# pntadm -A 10.13.22.101 10.13.22.0
Create the DHCP new options.
# dhtadm -A -s SrootOpt -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,1,ASCII,1,0'
# dhtadm -A -s SrootIP4 -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,2,IP,1,1'
# dhtadm -A -s SrootNM -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,3,ASCII,1,0'
# dhtadm -A -s SrootPTH -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,4,ASCII,1,0'
# dhtadm -A -s SswapIP4 -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,5,IP,1,0'
# dhtadm -A -s SswapPTH -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,6,ASCII,1,0'
# dhtadm -A -s SbootFIL -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,7,ASCII,1,0'
# dhtadm -A -s Stz -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,8,ASCII,1,0'
# dhtadm -A -s SbootRS -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,9,NUMBER,2,1'
# dhtadm -A -s SinstIP4 -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,10,IP,1,1'
# dhtadm -A -s SinstNM -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,11,ASCII,1,0'
# dhtadm -A -s SinstPTH -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,12,ASCII,1,0'
# dhtadm -A -s SsysidCF -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,13,ASCII,1,0'
# dhtadm -A -s SjumpsCF -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,14,ASCII,1,0'
# dhtadm -A -s Sterm -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,15,ASCII,1,0'
# dhtadm -A -s SbootURI -d 'Vendor=SUNW.Ultra-1 SUNW.Ultra-30
SUNW.i86pc,16,ASCII,1,0'
Configure DHCP server for network booting by creating the DHCP macro using the following commands:
# dhtadm -A -m PXEClient:Arch:00000:UNDI:002001 -d ':BootFile="nbp.SUNW.i86pc" \
:BootSrvA=10.13.22.100:SbootFIL="SUNW.i86pc":'
# dhtadm -A -m SUNW.i86pc -d \
':SinstNM="server1":SinstIP4=10.13.22.100:SinstPTH="/export/install/ia_9":\
SrootNM="server1":SrootIP4=10.13.22.100:SrootPTH="/export/install/ia_9/Solaris_9/Tools/Boot":'
Configure the Client.
In the installation server's Tools directory, set up the installation client:
# ./add_install_client -d SUNW.i86pc i86pc
Reboot the DHCP Server.
# pkill -HUP in.dhcpd
Boot the Client.
Expected Results
References
Required Hardware
Required Software
Test Strategy
Test Procedure
Verify that the system is running.
Install the driver by inserting the driver media.
For a realmode driver in pkg_drv format, type the following:
# volcheck
# /floppy/floppy0/DU/sol_xx/i86pc/Tools/install.sh -i
xx is the Solaris release number, for example, sol_9.
For a protected mode (Solaris) driver in pkgadd format, type the following:
# volcheck
# cd /floppy/floppy0
# pkgadd -d . $PKG_NAME
Reboot the system, if necessary.
Use the Driver Post-Installation Checklist to verify that the driver is installed correctly.
Expected Results
Required Hardware
Test Strategy
Test Procedure
Verify that one of these two sets of files are present.
driver_name is the name of the driver under test.
Verify that entries for the installed driver appear in these files:
For example, to locate the ncrs driver entry in the /etc/name_to_major file, type:
# grep ncrs /etc/name_to_major
ncrs 20
Expected Results
The files /kernel/drv/driver_name and
/kernel/drv/driver_name.conf exist
or
The files /platform/i86pc/kernel/drv/driver_name and
/platform/i86pc/kernel/drv/driver_name.conf exist.
Each of these files contains an entry for the driver installed:
Required Hardware
Network controller(s) supported by the driver under test
Another machine connected through the network to the test machine, either back-to-back or through a concentrator
Test Strategy
This test ensures that the driver can survive a boot when the connecting cable is either missing or disconnected while the system is active. The driver should be able to tolerate any loss of connectivity.
Test Procedure
Bring down the system.
Disconnect all cables belonging to the controller supported by the driver under test.
Reboot the system. If any error messages display, verify that they are from the driver and indicate that a cable is disconnected. The system should continue booting normally.
Using the ifconfig command, verify that the driver has configured the interface properly.
Bring down the system.
Reconnect the cables that were disconnected in Step 2.
Reboot the system; it should boot correctly.
Verify that the connection works correctly again.
Disconnect the cables while the system is running. The only error messages that should display are those indicating the connection is lost. The system continues working correctly.
Attempt a basic network connection, such as telnet(1) or ftp(1), to another machine. The connection should not be successful, but the rest of the system should be unaffected.
Reconnect the cables and attempt a basic connection again. It should succeed.
Expected Results
Required Hardware
Network controller supported by the driver under test
Another machine connected to the controller supported by the driver under test, either through a switch or back-to-back
Note: The multiprocessor machine (see System Configuration II) might be the only one to have a PCI bridge.
Test Strategy
This test ensures that the controller works correctly when inserted in a PCI slot that is behind a PCI bridge.
Test Procedure
Bring down the system and turn off the machine.
Open the case and move the controller supported by the driver under test to a slot behind a PCI bridge on the motherboard.
Reboot the system. Check that there are no error messages. For some drivers, it might be necessary to reconfigure the network such that the instance of the driver used is different. For example, if the driver is called abc and the instance originally used was abc0, you might now be using instance abc1. If so, rename the host file as appropriate, as shown in this example.
# mv /etc/hostname.abc0 /etc/hostname.abc1
Then reboot the system again, and check that the controller is configured correctly.
Expected Results
The controller works as before, with no loss of performance or configuration issues.
Required Hardware
Network controller supported by the driver under test
Another machine connected to the controller supported by the driver under test, either through a switch or back-to-back
Test Strategy
This test ensures that the controller works correctly when inserted in any slot in the machine.
Test Procedure
Bring down the system and turn off the machine.
Open the case and move the controller supported by the driver under test to a different slot on the motherboard.
Reboot the system. Verify that there are no error messages. For some drivers, it might be necessary to reconfigure the network such that the instance of the driver used is different. For example, if the driver is called abc and the instance originally used was abc0, you might now be using instance abc1. If so, rename the host file as appropriate, as shown in this example.
# mv /etc/hostname.abc0 /etc/hostname.abc1
Then reboot the system again, and check that the controller is configured correctly.
Repeat this procedure for every slot in the machine.
Expected Results
The controller works as before, with no loss of performance or configuration issues, regardless of the PCI slot used.
Required Hardware
Network controllers supported by the driver under test
Another machine connected to each controller supported by the driver under test, either through a switch or back-to-back
Test Strategy
This test ensures that the driver can handle a system with all slots in use, such as a router.
Test Procedure
Bring down the system and turn off the machine.
Open the case and add a network controller of the same type to all vacant PCI slots in the machine.
Reboot the system. Check that there are no error messages.
Prevent the machine from acting as a router.
# touch /etc/notrouter
Configure each additional interface with a separate IP address by using the ifconfig command. For example, if the original controller was abc0 and had address 192.168.10.1, you might configure the next controller using this command.
ifconfig abc1 inet 192.168.20.1 netmask + broadcast + up
Check the basic functionality of all controllers. Tests using separate interfaces work correctly in parallel.
Expected Results
All controllers work correctly, with no interference between the interfaces.
Required Hardware
Test Strategy
This test ensures that the driver does not cause a panic or hang the operating system if the corresponding controller is missing.
Test Procedure
Bring down the system and turn off the machine.
Open the case and remove all network controllers associated with the driver under test.
Reboot the system. Check that the only error messages are from the driver, indicating that the controller(s) are missing. The system should then continue booting normally.
Expected Results
There is an error message about the missing controller, but the system continues to boot normally. Any delays caused by the driver searching for the missing controller are not unreasonable.
Required Hardware
Two test machines
Two network controllers supported by the driver under test, one per test machine
A 100-Mbps switch supporting 100-Mbps and 10-Mbps transmission or a 1000-Mbps switch supporting 1000-Mbps, 100-Mbps, and 10-Mbps transmission, appropriate for the technology you are testing.
Test Strategy
This test ensures that the driver is capable of automatically detecting the highest transmission speed while the interface is active.
Test Procedure
Connect both machines to the 10-Mbps ports or switch, and boot both systems.
Display various driver and controller settings.
# kstat driver | grep -i ifspeed
For a 10-Mbps connection, this is shown:
ifspeed 10000000
Disconnect both machines from the 10-Mbps ports or switch, and connect them to the 100-Mbps ports or switch.
Display various driver and controller settings.
# kstat driver | grep -i ifspeed
For a 100-Mbps connection, this is shown:
ifspeed 100000000
Change the connections back to the 10-Mbps ports or switch, and verify that the connection speed has dropped back to 10000000.
Repeat these tests while executing a TCP stress test from the HCTS, such as ftpstress or rcp.
Expected Results
Required Hardware
Test Strategy
This test ensures that the driver is capable of automatically detecting whether the connection should be established in full-duplex or half-duplex mode while the interface is active.
Test Procedure
Set two ports on the switch to half-duplex only, and another two ports to full-duplex only. (See the switch hardware's documentation for instructions.)
Connect the systems to the half-duplex ports, and boot both systems.
Display various driver and controller settings.
# kstat driver | grep -i duplex
One shows:
duplex half
Disconnect both systems from the half-duplex ports, and connect them to the full-duplex ports.
Display various driver and controller settings.
# kstat driver | grep -i duplex
One shows:
duplex full
Change the connections back to the half-duplex ports, and verify that the controller has changed to half-duplex mode.
Repeat these tests while executing a TCP stress test from the HCTS, such as ftpstress or rcp.
Expected Results
Copyright 2005 Sun Microsystems, Inc. All rights reserved.