Chapter 12

To run all test cases in the various UMLs, run:

$ cd /umls/openswan/openswan-2 $ make check

This will take a few hours, depending on your hardware. To present the results, run:

$ source umlsetup.sh

$ perl testing/utils/regress-summarize-results.pl $REGRESSRESULTS

This will produce results/testresults.html which is a hyperlinked summary of the entire test run.

You can also run a single test. For example, to just run the xauth-pluto-09 test, you would use:

$ cd testing/pluto/xauth-pluto-09 $ ../../runme.sh

If you find an error in Openswan, creating a test case such as those that exist in the testing directory, and mailing that back to the Openswan developer list ([e-mail]) is by far the best way to report a bug. And once it is fixed, the test will remain part of Openswan, and all subsequent versions will test this specific case that went wrong once. If you write extensions to Openswan, then adding a test case is mandatory for the developers to incorporate the new code.

Writing a UML Test Case

Writing your own test case is not that difficult. Usually you can take an existing test, copy it, and then slightly modify it to represent the scenario you know causes a software error or kernel panic. Determine what type of test case you are writing—KLIPS, pluto, packaging, kernelconfig, utils, or something else. Create a new subdirectory under the proper subdirectory of testing/.

Populate that directory with the test files. Find an existing test that does something similar to what you are trying, and copy the files in and modify them. Add your test to testing/TEST-

TYPE/TESTLIST.

Edit the description.txt file to explain what your test case is actually testing, and possibly what problem you have encountered that you are trying to trigger with this test. Use ASCII-art drawings if it will make things clearer.

Then edit testparms.sh, which is largely self explanatory:

#!/bin/sh

#There are two main purposes, regress, or goal.

#goal: something that must pass for a release

#regress: a feature we always want to test, in case new code breaks it TEST_PURPOSE=regress

TEST_PROB_REPORT=0

#There are several 'types' of tests

#umlplutotest - Testing pluto under UML

#klipstest - Test KLIPS

#ctltest - ?

#mkinsttest - Test of 'make install'

#kernel_patch_test - Test patching of a kernel

#module_compile - Test building of the ipsec.o module

#umlXhost - Test involving several UML hosts

299

Debugging and Troubleshooting

TEST_TYPE=umlplutotest

#The name of the test. Must not be duplicated elsewhere in the testing tree. TESTNAME=dpd-01

#UML virtual 'hosts' you want to run

EASTHOST=east

WESTHOST=west

#Output files for each hosts's console REF_EAST_CONSOLE_OUTPUT=east-console.txt REF_WEST_CONSOLE_OUTPUT=west-console.txt

#Scripts to run against the console.txt files. These remove specific version #s, or # other variable strings and swap in CONSTANTS. REF_CONSOLE_FIXUPS="kern-list-fixups.sed nocr.sed" REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS cutout.sed" REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS east-prompt-splitline.pl" REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS ipsec-look-esp-sanitize.pl" REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS klips-debug-sanitize.sed" REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS ipsec-setup-sanitize.sed" REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS pluto-whack-sanitize.sed" REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS host-ping-sanitize.sed"

#Initialization scripts. Usually one per host. Use these to start ipsec, load

#a conn

EAST_INIT_SCRIPT=eastinit.sh

WEST_INIT_SCRIPT=westinit.sh

#These are the scripts that normally run your test

#Note1: These do NOT run in parallel. They are run one at a time.

#For play-by-play, interaction, use EAST_RUN2_SCRIPT=eastrun2.sh, etc...

#Note2: East is run before west

#

EAST_RUN_SCRIPT=eastrun.sh WEST_RUN_SCRIPT=westrun.sh

#Scripts to run at the end. Useful to tail /tmp/pluto.log, or

#'ipsec auto --look' to get a final look at the state of things. EAST_FINAL_SCRIPT=final.sh

WEST_FINAL_SCRIPT=final.sh

NETJIG_EXTRA=debugpublic.txt

There is a timeout to catch when a process does not return to a prompt for the *init.sh, *run.sh scripts. For this reason, do not do things like 'sleep 60'—instead, use 'sleep 10' six times.

Now your test is ready to run, and to be submitted to the developer mailing list for inclusion in Openswan.

Debugging the Kernel with GDB

With User Mode Linux, you can debug the kernel using GDB.

See http://user-mode-linux.sourceforge.net/debugging.htm.

Typically, you will have one test failing with a kernel crash, so you want to run just that one test. First start GDB. Tell it to open the $POOLSPACE/swan/Linux program. Check the PID of GDB:

300