524 lines
25 KiB
HTML
524 lines
25 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Introduction to FreeS/WAN</TITLE>
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
|
|
<STYLE TYPE="text/css"><!--
|
|
BODY { font-family: serif }
|
|
H1 { font-family: sans-serif }
|
|
H2 { font-family: sans-serif }
|
|
H3 { font-family: sans-serif }
|
|
H4 { font-family: sans-serif }
|
|
H5 { font-family: sans-serif }
|
|
H6 { font-family: sans-serif }
|
|
SUB { font-size: smaller }
|
|
SUP { font-size: smaller }
|
|
PRE { font-family: monospace }
|
|
--></STYLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="umltesting.html">Previous</A>
|
|
<A HREF="nightly.html">Next</A>
|
|
<HR>
|
|
<H1><A name="makecheck">How to configure to use "make check"</A></H1>
|
|
<H2><A NAME="38_1">What is "make check"</A></H2>
|
|
<P> "make check" is a target in the top level makefile. It takes care of
|
|
running a number of unit and system tests to confirm that FreeSWAN has
|
|
been compiled correctly, and that no new bugs have been introduced.</P>
|
|
<P> As FreeSWAN contains both kernel and userspace components, doing
|
|
testing of FreeSWAN requires that the kernel be simulated. This is
|
|
typically difficult to do as a kernel requires that it be run on bare
|
|
hardware. A technology has emerged that makes this simpler. This is<A HREF="http://user-mode-linux.sourceforge.net">
|
|
User Mode Linux</A>.</P>
|
|
<P> User-Mode Linux is a way to build a Linux kernel such that it can
|
|
run as a process under another Linux (or in the future other) kernel.
|
|
Presently, this can only be done for 2.4 guest kernels. The host kernel
|
|
can be 2.2 or 2.4.</P>
|
|
<P> "make check" expects to be able to build User-Mode Linux kernels
|
|
with FreeSWAN included. To do this it needs to have some files
|
|
downloaded and extracted prior to running "make check". This is
|
|
described in the<A HREF="umltesting.html"> UML testing</A> document.</P>
|
|
<P> After having run the example in the UML testing document and
|
|
successfully brought up the four machine combination, you are ready to
|
|
use "make check"</P>
|
|
<H2><A NAME="38_2">Running "make check"</A></H2>
|
|
<P> "make check" works by walking the FreeSWAN source tree invoking the
|
|
"check" target at each node. At present there are tests defined only
|
|
for the <CODE>klips</CODE> directory. These tests will use the UML
|
|
infrastructure to test out pieces of the <CODE>klips</CODE> code.</P>
|
|
<P> The results of the tests can be recorded. If the environment
|
|
variable <CODE>$REGRESSRESULTS</CODE> is non-null, then the results of
|
|
each test will be recorded. This can be used as part of a nightly
|
|
regression testing system, see<A HREF="nightly.html"> Nightly testing</A>
|
|
for more details.</P>
|
|
<P> "make check" otherwise prints a minimal amount of output for each
|
|
test, and indicates pass/fail status of each test as they are run.
|
|
Failed tests do not cause failure of the target in the form of exit
|
|
codes.</P>
|
|
<H1><A NAME="39">How to write a "make check" test</A></H1>
|
|
<H2><A NAME="39_1">Structure of a test</A></H2>
|
|
<P> Each test consists of a set of directories under <CODE>testing/</CODE>
|
|
. There are directories for <CODE>klips</CODE>, <CODE>pluto</CODE>, <CODE>
|
|
packaging</CODE> and <CODE>libraries</CODE>. Each directory has a list
|
|
of tests to run is stored in a file called <CODE>TESTLIST</CODE> in
|
|
that directory. e.g. <CODE>testing/klips/TESTLIST</CODE>.</P>
|
|
<H2 NAME="TESTLIST"><A NAME="39_2">The TESTLIST</A></H2>
|
|
<P> This isn't actually a shell script. It just looks like one. Some
|
|
tools other than /bin/sh process it. Lines that start with # are
|
|
comments.</P>
|
|
<PRE>
|
|
# test-kind directory-containing-test expectation [PR#]
|
|
</PRE>
|
|
<P>The first word provides the test type, detailed below.</P>
|
|
<P> The second word is the name of the test to run. This the directory
|
|
in which the test case is to be found..</P>
|
|
<P>The third word may be one of:</P>
|
|
<DL>
|
|
<DT> blank/good</DT>
|
|
<DD>the test is believed to function, report failure</DD>
|
|
<DT> bad</DT>
|
|
<DD> the test is known to fail, report unexpected success</DD>
|
|
<DT> suspended</DT>
|
|
<DD> the test should not be run</DD>
|
|
</DL>
|
|
<P> The fourth word may be a number, which is a PR# if the test is
|
|
failing.</P>
|
|
<H2><A NAME="39_3">Test kinds</A></H2>
|
|
The test types are:
|
|
<DL>
|
|
<DT>skiptest</DT>
|
|
<DD>means run no test.</DD>
|
|
<DT>ctltest</DT>
|
|
<DD>means run a single system without input/output.</DD>
|
|
<DT>klipstest</DT>
|
|
<DD>means run a single system with input/output networks</DD>
|
|
<DT><A HREF="#umlplutotest">umlplutotest</A></DT>
|
|
<DD>means run a pair of systems</DD>
|
|
<DT><A HREF="#umlXhost">umlXhost</A></DT>
|
|
<DD>run an arbitrary number of systems</DD>
|
|
<DT>suntest (TBD)</DT>
|
|
<DD>means run a quad of east/west/sunrise/sunset</DD>
|
|
<DT>roadtest (TBD)</DT>
|
|
<DD>means run a trio of east-sunrise + warrior</DD>
|
|
<DT>extrudedtest (TBD)</DT>
|
|
<DD>means run a quad of east-sunrise + warriorsouth + park</DD>
|
|
<DT>mkinsttest</DT>
|
|
<DD>a test of the "make install" machinery.</DD>
|
|
<DT>kernel_test_patch</DT>
|
|
<DD>a test of the "make kernelpatch" machinery.</DD>
|
|
</DL>
|
|
Tests marked (TBD) have yet to be fully defined.
|
|
<P> Each test directory has a file in it called <CODE>testparams.sh</CODE>
|
|
. This file sets a number of environment variables to define the
|
|
parameters of the test.</P>
|
|
<H2><A NAME="39_4">Common parameters</A></H2>
|
|
<DL>
|
|
<DT>TESTNAME</DT>
|
|
<DD>the name of the test (repeated for checking purposes)</DD>
|
|
<DT>TEST_TYPE</DT>
|
|
<DD>the type of the test (repeat of type type above)</DD>
|
|
<DT>TESTHOST</DT>
|
|
<DD>the name of the UML machine to run for the test, typically "east" or
|
|
"west"</DD>
|
|
<DT>TEST_PURPOSE</DT>
|
|
<DD>The purpose of the test is one of:
|
|
<DL>
|
|
<DT>goal</DT>
|
|
<DD>The goal purpose is where a test is defined for code that is not yet
|
|
finished. The test indicates when the goals have in fact been reached.</DD>
|
|
<DT>regress</DT>
|
|
<DD>This is a test to determine that a previously existing bug has been
|
|
repaired. This test will initially be created to reproduce the bug in
|
|
isolation, and then the bug will be fixed.</DD>
|
|
<DT>exploit</DT>
|
|
<DD>This is a set of packets/programs that causes a vulnerability to be
|
|
exposed. It is a specific variation of the regress option.</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>TEST_GOAL_ITEM</DT>
|
|
<DT></DT>
|
|
<DD>in the case of a goal test, this is a reference to the requirements
|
|
document</DD>
|
|
<DT>TEST_PROB_REPORT</DT>
|
|
<DD>in the case of regression test, this the problem report number from
|
|
GNATS</DD>
|
|
<DT>TEST_EXPLOIT_URL</DT>
|
|
<DD>in the case of an exploit, this is a URL referencing the paper
|
|
explaining the origin of the test and the origin of exploit software</DD>
|
|
<DT>REF_CONSOLE_OUTPUT</DT>
|
|
<DD>a file in the test directory that contains the sanitized console
|
|
output against which to compare the output of the actual test.</DD>
|
|
<DT>REF_CONSOLE_FIXUPS</DT>
|
|
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
|
|
to sanitize the console output of the machine under test. These are
|
|
typically perl, awk or sed scripts that remove things in the kernel
|
|
output that change each time the test is run and/or compiled.</DD>
|
|
<DT>INIT_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode prior to starting the tests. This file will usually
|
|
set up any eroute's and SADB entries that are required for the test.</P>
|
|
<P>Lines beginning with # are skipped. Blank lines are skipped.
|
|
Otherwise, a shell prompted is waited for each time (consisting of <CODE>
|
|
\n#</CODE>) and then the command is sent. Note that the prompt is waited
|
|
for before the command and not after, so completion of the last command
|
|
in the script is not required. This is often used to invoke a program
|
|
to monitor the system, e.g. <CODE>ipsec pf_key</CODE>.</P>
|
|
</DD>
|
|
<DT>RUN_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode, before the packets are sent. On single machine tests,
|
|
this script doesn't provide any more power than INIT_SCRIPT, but is
|
|
implemented for consistency's sake.</P>
|
|
</DD>
|
|
<DT>FINAL_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode after the final packet is sent. Similar to
|
|
INIT_SCRIPT, above. If not specified, then the single command "halt" is
|
|
sent. If specified, then the script should end with a halt command to
|
|
nicely shutdown the UML.</P>
|
|
</DD>
|
|
<DT>CONSOLEDIFFDEBUG</DT>
|
|
<DD>If set to "true" then the series of console fixups (see
|
|
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
|
|
be set to "false", or unset otherwise)</DD>
|
|
<DT>NETJIGDEBUG</DT>
|
|
<DD>If set to "true" then the series of console fixups (see
|
|
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
|
|
be set to "false", or unset otherwise)</DD>
|
|
<DT>NETJIGTESTDEBUG</DT>
|
|
<DD> If set to "netjig", then the results of talking to the <CODE>
|
|
uml_netjig</CODE> will be printed to stderr during the test. In
|
|
addition, the jig will be invoked with --debug, which causes it to log
|
|
its process ID, and wait 60 seconds before continuing. This can be used
|
|
if you are trying to debug the <CODE>uml_netjig</CODE> program itself.</DD>
|
|
<DT>HOSTTESTDEBUG</DT>
|
|
<DD> If set to "hosttest", then the results of taling to the consoles of
|
|
the UMLs will be printed to stderr during the test.</DD>
|
|
<DT>NETJIGWAITUSER</DT>
|
|
<DD> If set to "waituser", then the scripts will wait forever for user
|
|
input before they shut the tests down. Use this is if you are debugging
|
|
through the kernel.</DD>
|
|
<DT>PACKETRATE</DT>
|
|
<DD> A number, in miliseconds (default is 500ms) at which packets will
|
|
be replayed by the netjig.</DD>
|
|
</DL>
|
|
<H2><A NAME="39_5">KLIPStest paramaters</A></H2>
|
|
<P> The klipstest function starts a program (<CODE>
|
|
testing/utils/uml_netjig/uml_netjig</CODE>) to setup a bunch of I/O
|
|
sockets (that simulate network interfaces). It then exports the
|
|
references to these sockets to the environment and invokes (using
|
|
system()) a given script. It waits for the script to finish.</P>
|
|
|
|
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
|
|
<P> The script invoked (<CODE>testing/utils/host-test.tcl</CODE>) is a
|
|
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
|
|
to start the UML and configure it appropriately for the test. The
|
|
configuration is done with the script given above for<VAR> INIT_SCRIPT</VAR>
|
|
. The TCL script then forks, leaves the UML in the background and exits.
|
|
uml_netjig continues. It then starts listening to the simulated network
|
|
answering ARPs and inserting packets as appropriate.</P>
|
|
<P> The klipstest function invokes <CODE>uml_netjig</CODE> with
|
|
arguments to capture output from network interface(s) and insert
|
|
packets as appropriate:</P>
|
|
<DL>
|
|
<DT>PUB_INPUT</DT>
|
|
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
|
|
public (encrypted) interface. (typically, eth1)</DD>
|
|
<DT>PRIV_INPUT</DT>
|
|
<DD>a pcap file to feed in on the private (plain-text) interface
|
|
(typically, eth0).</DD>
|
|
<DT>REF_PUB_OUTPUT</DT>
|
|
<DD>a text file containing tcpdump output. Packets on the public (eth1)
|
|
interface are captured to a<A HREF="http://www.tcpdump.org/"> pcap</A>
|
|
file by <CODE>uml_netjig</CODE>. The klipstest function then uses
|
|
tcpdump on the file to produce text output, which is compared to the
|
|
file given.</DD>
|
|
<DT>REF_PUB_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<DT>REF_PRIV_OUTPUT</DT>
|
|
<DD>a text file containing tcpdump output. Packets on the private (eth0)
|
|
interface are captured and compared after conversion by tcpdump, as
|
|
with<VAR> REFPUBOUTPUT</VAR>.</DD>
|
|
<DT>REF_PRIV_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<DT>EXITONEMPTY</DT>
|
|
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain
|
|
"--exitonempty" of uml_netjig should exit when all of the input (<VAR>
|
|
PUBINPUT</VAR>,<VAR>PRIVINPUT</VAR>) packets have been injected.</DD>
|
|
<DT>ARPREPLY</DT>
|
|
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain "--arpreply"
|
|
if <CODE>uml_netjig</CODE> should reply to ARP requests. One will
|
|
typically set this to avoid having to fudge the ARP cache manually.</DD>
|
|
<DT>TCPDUMPFLAGS</DT>
|
|
<DD>a set of flags for the tcpdump used when converting captured output.
|
|
Typical values will include "-n" to turn off DNS, and often "-E" to set
|
|
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
|
|
"-t" flag (turn off timestamps) is provided automatically</DD>
|
|
<DT>NETJIG_EXTRA</DT>
|
|
<DD>additional comments to be sent to the netjig. This may arrange to
|
|
record or create additional networks, or may toggle options.</DD>
|
|
</DL>
|
|
<H2><A NAME="39_6">mkinsttest paramaters</A></H2>
|
|
<P> The basic concept of the <CODE>mkinsttest</CODE> test type is that
|
|
it performs a "make install" to a temporary $DESTDIR. The resulting
|
|
tree can then be examined to determine if it was done properly. The
|
|
files can be uninstalled to determine if the file list was correct, or
|
|
the contents of files can be examined more precisely.</P>
|
|
<DL>
|
|
<DT>INSTALL_FLAGS</DT>
|
|
<DD>If set, then an install will be done. This provides the set of flags
|
|
to provide for the install. The target to be used (usually "install")
|
|
must be among the flags.</DD>
|
|
<DT>POSTINSTALL_SCRIPT</DT>
|
|
<DD>If set, a script to run after initial "make install". Two arguments
|
|
are provided: an absolute path to the root of the FreeSWAN src tree,
|
|
and an absolute path to the temporary installation area.</DD>
|
|
<DT>INSTALL2_FLAGS</DT>
|
|
<DD>If set, a second install will be done using these flags. Similarly
|
|
to INSTALL_FLAGS, the target must be among the flags.</DD>
|
|
<DT>UNINSTALL_FLAGS</DT>
|
|
<DD>If set, an uninstall will be done using these flags. Similarly to
|
|
INSTALL_FLAGS, the target (usually "uninstall") must be among the
|
|
flags.</DD>
|
|
<DT>REF_FIND_f_l_OUTPUT</DT>
|
|
<DD>If set, a <CODE>find $ROOT ( -type f -or -type -l )</CODE> will be
|
|
done to get a list of a real files and symlinks. The resulting file
|
|
will be compared to the file listed by this option.</DD>
|
|
<DT>REF_FILE_CONTENTS</DT>
|
|
<DD>If set, it should point to a file containing records for the form:
|
|
<PRE>
|
|
|
|
<!--VARIABLE-->
|
|
reffile</(null)>
|
|
<!--VARIABLE-->
|
|
samplefile</(null)>
|
|
</PRE>
|
|
one record per line. A diff between the provided reference file, and
|
|
the sample file (located in the temporary installation root) will be
|
|
done for each record.</DD>
|
|
</DL>
|
|
<H2><A NAME="39_7">rpm_build_install_test paramaters</A></H2>
|
|
<P> The <CODE>rpm_build_install_test</CODE> type is to verify that the
|
|
proper packing list is produced by "make rpm", and that the mechanisms
|
|
for building the kernel modules produce consistent results.</P>
|
|
<DL>
|
|
<DT>RPM_KERNEL_SOURCE</DT>
|
|
<DD>Point to an extracted copy of the RedHat kernel source code.
|
|
Variables from the environment may be used.</DD>
|
|
<DT>REF_RPM_CONTENTS</DT>
|
|
<DD>This is a file containing one record per line. Each record consists
|
|
of a RPM name (may contain wildcards) and a filename to compare the
|
|
contents to. The RPM will be located and a file list will be produced
|
|
with rpm2cpio.</DD>
|
|
</DL>
|
|
<H2><A NAME="39_8">libtest paramaters</A></H2>
|
|
<P> The libtest test is for testing library routines. The library file
|
|
is expected to provided an <CODE>#ifdef</CODE> by the name of<VAR>
|
|
library</VAR>
|
|
<!--CODE_MAIN</CODE-->
|
|
. The libtest type invokes the C compiler to compile this
|
|
file, links it against <CODE>libfreeswan.a</CODE> (to resolve any other
|
|
dependancies) and runs the test with the <CODE>-r</CODE> argument to
|
|
invoke a regression test.</(null)></P>
|
|
<P>The library test case is expected to do a self-test, exiting with
|
|
status code 0 if everything is okay, and with non-zero otherwise. A
|
|
core dump (exit code greater than 128) is noted specifically.</P>
|
|
<P> Unlike other tests, there are no subdirectories required, or other
|
|
parameters to set.</P>
|
|
<H2 NAME="umlplutotest"><A NAME="39_9">umlplutotest paramaters</A></H2>
|
|
<P> The umlplutotest function starts a pair of user mode line processes.
|
|
This is a 2-host version of umlXhost. The "EAST" and "WEST" slots are
|
|
defined.</P>
|
|
<H2 NAME="umlXhost"><A NAME="39_10">umlXhost parameters</A></H2>
|
|
<P> The umlXtest function starts an arbitrary number of user mode line
|
|
processes.</P>
|
|
|
|
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
|
|
<P> The script invoked (<CODE>testing/utils/Xhost-test.tcl</CODE>) is a
|
|
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
|
|
to start each UML and configure it appropriately for the test. It then
|
|
starts listening (using uml_netjig) to the simulated network answering
|
|
ARPs and inserting packets as appropriate.</P>
|
|
<P> umlXtest has a series of slots, each of which should be filled by a
|
|
host. The list of slots is controlled by the variable, XHOST_LIST. This
|
|
variable should be set to a space seperated list of slots. The former
|
|
umlplutotest is now implemented as a variation of the umlXhost test,
|
|
with XHOST_LIST="EAST WEST".</P>
|
|
<P> For each host slot that is defined, a series of variables should be
|
|
filled in, defining what configuration scripts to use for that host.</P>
|
|
<P> The following are used to control the console input and output to
|
|
the system. Where the string ${host} is present, the host slot should
|
|
be filled in. I.e. for the two host system with XHOST_LIST="EAST WEST",
|
|
then the variables: EAST_INIT_SCRIPT and WEST_INIT_SCRIPT will exist.</P>
|
|
<DL>
|
|
<DT>${host}HOST</DT>
|
|
<DD>The name of the UML host which will fill this slot</DD>
|
|
<DT>${host}_INIT_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode prior to starting the tests. This file will usually
|
|
set up any eroute's and SADB entries that are required for the test.
|
|
Similar to INIT_SCRIPT, above.</P>
|
|
</DD>
|
|
<DT>${host}_RUN_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode, before the packets are sent. This set of commands is
|
|
run after all of the virtual machines are initialized. I.e. after
|
|
EAST_INIT_SCRIPT<B> AND</B> WEST_INIT_SCRIPT. This script can therefore
|
|
do things that require that all machines are properly configured.</P>
|
|
</DD>
|
|
<DT>${host}_RUN2_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode, after the packets are sent. This set of commands is
|
|
run before any of the virtual machines have been shut down. (I.e.
|
|
before EAST_FINAL_SCRIPT<B> AND</B> WEST_FINAL_SCRIPT.) This script can
|
|
therefore catch post-activity status reports.</P>
|
|
</DD>
|
|
<DT>${host}_FINAL_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode after the final packet is sent. Similar to
|
|
INIT_SCRIPT, above. If not specified, then the single command "halt" is
|
|
sent. Note that when this script is run, the other virtual machines may
|
|
already have been killed. If specified, then the script should end with
|
|
a halt command to nicely shutdown the UML.</P>
|
|
</DD>
|
|
<DT>REF_${host}_CONSOLE_OUTPUT</DT>
|
|
<DD>Similar to REF_CONSOLE_OUTPUT, above.</DD>
|
|
</DL>
|
|
<P>Some additional flags apply to all hosts:</P>
|
|
<DL>
|
|
<DT>REF_CONSOLE_FIXUPS</DT>
|
|
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
|
|
to sanitize the console output of the machine under test. These are
|
|
typically perl, awk or sed scripts that remove things in the kernel
|
|
output that change each time the test is run and/or compiled.</DD>
|
|
</DL>
|
|
<P> In addition to input to the console, the networks may have input fed
|
|
to them:</P>
|
|
<DL>
|
|
<DT>EAST_INPUT/WEST_INPUT</DT>
|
|
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
|
|
private network side of each network. The "EAST" and "WEST" here refer
|
|
to the networks, not the hosts.</DD>
|
|
<DT>REF_PUB_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<DT>REF_EAST_FILTER/REF_WEST_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<
|
|
<DT>TCPDUMPFLAGS</DT>
|
|
<DD>a set of flags for the tcpdump used when converting captured output.
|
|
Typical values will include "-n" to turn off DNS, and often "-E" to set
|
|
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
|
|
"-t" flag (turn off timestamps) is provided automatically</DD>
|
|
<DT>REF_EAST_OUTPUT/REF_WEST_OUTPUT</DT>
|
|
<DD>a text file containing tcpdump output. Packets on the private (eth0)
|
|
interface are captured and compared after conversion by tcpdump, as
|
|
with<VAR> REF_PUB_OUTPUT</VAR>.</DD>
|
|
<P> There are two additional environment variables that may be set on
|
|
the command line:</P>
|
|
<DL>
|
|
<DT> NETJIGVERBOSE=verbose export NETJIGVERBOSE</DT>
|
|
<DD> If set, then the test output will be "chatty", and let you know
|
|
what commands it is running, and as packets are sent. Without it set,
|
|
the output is limited to success/failure messages.</DD>
|
|
<DT> NETJIGTESTDEBUG=netjig export NETJIGTESTDEBUG</DT>
|
|
<DD> This will enable debugging of the communication with uml_netjig,
|
|
and turn on debugging in this utility. This does not imply
|
|
NETJIGVERBOSE.</DD>
|
|
</DL>
|
|
<DT> HOSTTESTDEBUG=hosttest export HOSTTESTDEBUG</DT>
|
|
<DD> This will show all interactions with the user-mode-linux consoles</DD>
|
|
</DL>
|
|
<H2 NAME="kernelpatch"><A NAME="39_11">kernel_patch_test paramaters</A></H2>
|
|
<P> The kernel_patch_test function takes some kernel source, copies it
|
|
with lndir, and then applies the patch as produced by "make
|
|
kernelpatch".</P>
|
|
<P> The following are used to control the input and output to the
|
|
system:</P>
|
|
<DL>
|
|
<DT>KERNEL_NAME</DT>
|
|
<DD>the kernel name, typically something like "linus" or "rh"</DD>
|
|
<DT>KERNEL_VERSION</DT>
|
|
<DD>the kernel version number, as in "2.2" or "2.4".</DD>
|
|
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
|
|
<DD>This variable should set in the environment, probably in
|
|
~/freeswan-regress-env.sh. Examples of this variables would be
|
|
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
|
|
an extracted copy of the kernel source in question.</DD>
|
|
<DT>REF_PATCH_OUTPUT</DT>
|
|
<DD>a copy of the patch output to compare against</DD>
|
|
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
|
|
<DD>If set to a non-empty string, then the patched kernel source is not
|
|
removed at the end of the test. This will typically be set in the
|
|
environment while debugging.</DD>
|
|
</DL>
|
|
<H2 NAME="modtest"><A NAME="39_12">module_compile paramaters</A></H2>
|
|
<P> The module_compile test attempts to build the KLIPS module against a
|
|
given set of kernel source. This is also done by the RPM tests, but in
|
|
a very specific manner.</P>
|
|
<P> There are two variations of this test - one where the kernel either
|
|
doesn't need to be configured, or is already done, and tests were there
|
|
is a local configuration file.</P>
|
|
<P> Where the kernel doesn't need to be configured, the kernel source
|
|
that is found is simply used. It may be a RedHat-style kernel, where
|
|
one can cause it to configure itself via rhconfig.h-style definitions.
|
|
Or, it may just be a kernel tree that has been configured.</P>
|
|
<P> If the variable KERNEL_CONFIG_FILE is set, then a new directory is
|
|
created for the kernel source. It is populated with lndir(1). The
|
|
referenced file is then copied in as .config, and "make oldconfig" is
|
|
used to configure the kernel. This resulting kernel is then used as the
|
|
reference source.</P>
|
|
<P> In all cases, the kernel source is found the same was for the
|
|
kernelpatch test, i.e. via KERNEL_VERSION/KERNEL_NAME and
|
|
KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC.</P>
|
|
<P> Once there is kernel source, the module is compiled using the
|
|
top-level "make module" target.</P>
|
|
<P> The test is considered successful if an executable is found in
|
|
OUTPUT/module/ipsec.o at the end of the test.</P>
|
|
<DL>
|
|
<DT>KERNEL_NAME</DT>
|
|
<DD>the kernel name, typically something like "linus" or "rh"</DD>
|
|
<DT>KERNEL_VERSION</DT>
|
|
<DD>the kernel version number, as in "2.2" or "2.4".</DD>
|
|
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
|
|
<DD>This variable should set in the environment, probably in
|
|
~/freeswan-regress-env.sh. Examples of this variables would be
|
|
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
|
|
an extracted copy of the kernel source in question.</DD>
|
|
<DT>KERNEL_CONFIG_FILE</DT>
|
|
<DD>The configuration file for the kernel.</DD>
|
|
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
|
|
<DD>If set to a non-empty string, then the configured kernel source is
|
|
not removed at the end of the test. This will typically be set in the
|
|
environment while debugging.</DD>
|
|
<DT>MODULE_DEF_INCLUDE</DT>
|
|
<DD>The include file that will be used to configure the KLIPS module,
|
|
and possibly the kernel source.</DD>
|
|
</DL>
|
|
<H1><A NAME="40">Current pitfalls</A></H1>
|
|
<DL>
|
|
<DT> "tcpdump dissector" not available.</DT>
|
|
<DD> This is a non-fatal warning. If uml_netjig is invoked with the -t
|
|
option, then it will attempt to use tcpdump's dissector to decode each
|
|
packet that it processes. The dissector is presently not available, so
|
|
this option it normally turned off at compile time. The dissector
|
|
library will be released with tcpdump version 4.0.</DD>
|
|
</DL>
|
|
<HR>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="umltesting.html">Previous</A>
|
|
<A HREF="nightly.html">Next</A>
|
|
</BODY>
|
|
</HTML>
|