doc/makecheck.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <HTML>
   3 <HEAD>
   4 <TITLE>Introduction to FreeS/WAN</TITLE>
   5 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
   6 <STYLE TYPE="text/css"><!--
   7 BODY { font-family: serif }
   8 H1 { font-family: sans-serif }
   9 H2 { font-family: sans-serif }
  10 H3 { font-family: sans-serif }
  11 H4 { font-family: sans-serif }
  12 H5 { font-family: sans-serif }
  13 H6 { font-family: sans-serif }
  14 SUB { font-size: smaller }
  15 SUP { font-size: smaller }
  16 PRE { font-family: monospace }
  17 --></STYLE>
  18 </HEAD>
  19 <BODY>
  20 <A HREF="toc.html">Contents</A>
  21 <A HREF="umltesting.html">Previous</A>
  22 <A HREF="nightly.html">Next</A>
  23 <HR>
  24 <H1><A name="makecheck">How to configure to use &quot;make check&quot;</A></H1>
  25 <H2><A NAME="38_1">What is &quot;make check&quot;</A></H2>
  26 <P> &quot;make check&quot; is a target in the top level makefile. It takes care of
  27  running a number of unit and system tests to confirm that FreeSWAN has
  28  been compiled correctly, and that no new bugs have been introduced.</P>
  29 <P> As FreeSWAN contains both kernel and userspace components, doing
  30  testing of FreeSWAN requires that the kernel be simulated. This is
  31  typically difficult to do as a kernel requires that it be run on bare
  32  hardware. A technology has emerged that makes this simpler. This is<A HREF="http://user-mode-linux.sourceforge.net">
  33  User Mode Linux</A>.</P>
  34 <P> User-Mode Linux is a way to build a Linux kernel such that it can
  35  run as a process under another Linux (or in the future other) kernel.
  36  Presently, this can only be done for 2.4 guest kernels. The host kernel
  37  can be 2.2 or 2.4.</P>
  38 <P> &quot;make check&quot; expects to be able to build User-Mode Linux kernels
  39  with FreeSWAN included. To do this it needs to have some files
  40  downloaded and extracted prior to running &quot;make check&quot;. This is
  41  described in the<A HREF="umltesting.html"> UML testing</A> document.</P>
  42 <P> After having run the example in the UML testing document and
  43  successfully brought up the four machine combination, you are ready to
  44  use &quot;make check&quot;</P>
  45 <H2><A NAME="38_2">Running &quot;make check&quot;</A></H2>
  46 <P> &quot;make check&quot; works by walking the FreeSWAN source tree invoking the
  47  &quot;check&quot; target at each node. At present there are tests defined only
  48  for the <CODE>klips</CODE> directory. These tests will use the UML
  49  infrastructure to test out pieces of the <CODE>klips</CODE> code.</P>
  50 <P> The results of the tests can be recorded. If the environment
  51  variable <CODE>$REGRESSRESULTS</CODE> is non-null, then the results of
  52  each test will be recorded. This can be used as part of a nightly
  53  regression testing system, see<A HREF="nightly.html"> Nightly testing</A>
  54  for more details.</P>
  55 <P> &quot;make check&quot; otherwise prints a minimal amount of output for each
  56  test, and indicates pass/fail status of each test as they are run.
  57  Failed tests do not cause failure of the target in the form of exit
  58  codes.</P>
  59 <H1><A NAME="39">How to write a &quot;make check&quot; test</A></H1>
  60 <H2><A NAME="39_1">Structure of a test</A></H2>
  61 <P> Each test consists of a set of directories under <CODE>testing/</CODE>
  62 . There are directories for <CODE>klips</CODE>, <CODE>pluto</CODE>, <CODE>
  63 packaging</CODE> and <CODE>libraries</CODE>. Each directory has a list
  64  of tests to run is stored in a file called <CODE>TESTLIST</CODE> in
  65  that directory. e.g. <CODE>testing/klips/TESTLIST</CODE>.</P>
  66 <H2 NAME="TESTLIST"><A NAME="39_2">The TESTLIST</A></H2>
  67 <P> This isn't actually a shell script. It just looks like one. Some
  68  tools other than /bin/sh process it. Lines that start with # are
  69  comments.</P>
  70 <PRE>
  71 # test-kind     directory-containing-test       expectation     [PR#]
  72 </PRE>
  73 <P>The first word provides the test type, detailed below.</P>
  74 <P> The second word is the name of the test to run. This the directory
  75  in which the test case is to be found..</P>
  76 <P>The third word may be one of:</P>
  77 <DL>
  78 <DT> blank/good</DT>
  79 <DD>the test is believed to function, report failure</DD>
  80 <DT> bad</DT>
  81 <DD> the test is known to fail, report unexpected success</DD>
  82 <DT> suspended</DT>
  83 <DD> the test should not be run</DD>
  84 </DL>
  85 <P> The fourth word may be a number, which is a PR# if the test is
  86  failing.</P>
  87 <H2><A NAME="39_3">Test kinds</A></H2>
  88  The test types are:
  89 <DL>
  90 <DT>skiptest</DT>
  91 <DD>means run no test.</DD>
  92 <DT>ctltest</DT>
  93 <DD>means run a single system without input/output.</DD>
  94 <DT>klipstest</DT>
  95 <DD>means run a single system with input/output networks</DD>
  96 <DT><A HREF="#umlplutotest">umlplutotest</A></DT>
  97 <DD>means run a pair of systems</DD>
  98 <DT><A HREF="#umlXhost">umlXhost</A></DT>
  99 <DD>run an arbitrary number of systems</DD>
 100 <DT>suntest (TBD)</DT>
 101 <DD>means run a quad of east/west/sunrise/sunset</DD>
 102 <DT>roadtest (TBD)</DT>
 103 <DD>means run a trio of east-sunrise + warrior</DD>
 104 <DT>extrudedtest (TBD)</DT>
 105 <DD>means run a quad of east-sunrise + warriorsouth + park</DD>
 106 <DT>mkinsttest</DT>
 107 <DD>a test of the &quot;make install&quot; machinery.</DD>
 108 <DT>kernel_test_patch</DT>
 109 <DD>a test of the &quot;make kernelpatch&quot; machinery.</DD>
 110 </DL>
 111  Tests marked (TBD) have yet to be fully defined.
 112 <P> Each test directory has a file in it called <CODE>testparams.sh</CODE>
 113 . This file sets a number of environment variables to define the
 114  parameters of the test.</P>
 115 <H2><A NAME="39_4">Common parameters</A></H2>
 116 <DL>
 117 <DT>TESTNAME</DT>
 118 <DD>the name of the test (repeated for checking purposes)</DD>
 119 <DT>TEST_TYPE</DT>
 120 <DD>the type of the test (repeat of type type above)</DD>
 121 <DT>TESTHOST</DT>
 122 <DD>the name of the UML machine to run for the test, typically &quot;east&quot; or
 123  &quot;west&quot;</DD>
 124 <DT>TEST_PURPOSE</DT>
 125 <DD>The purpose of the test is one of:
 126 <DL>
 127 <DT>goal</DT>
 128 <DD>The goal purpose is where a test is defined for code that is not yet
 129  finished. The test indicates when the goals have in fact been reached.</DD>
 130 <DT>regress</DT>
 131 <DD>This is a test to determine that a previously existing bug has been
 132  repaired. This test will initially be created to reproduce the bug in
 133  isolation, and then the bug will be fixed.</DD>
 134 <DT>exploit</DT>
 135 <DD>This is a set of packets/programs that causes a vulnerability to be
 136  exposed. It is a specific variation of the regress option.</DD>
 137 </DL>
 138 </DD>
 139 <DT>TEST_GOAL_ITEM</DT>
 140 <DT></DT>
 141 <DD>in the case of a goal test, this is a reference to the requirements
 142  document</DD>
 143 <DT>TEST_PROB_REPORT</DT>
 144 <DD>in the case of regression test, this the problem report number from
 145  GNATS</DD>
 146 <DT>TEST_EXPLOIT_URL</DT>
 147 <DD>in the case of an exploit, this is a URL referencing the paper
 148  explaining the origin of the test and the origin of exploit software</DD>
 149 <DT>REF_CONSOLE_OUTPUT</DT>
 150 <DD>a file in the test directory that contains the sanitized console
 151  output against which to compare the output of the actual test.</DD>
 152 <DT>REF_CONSOLE_FIXUPS</DT>
 153 <DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
 154  to sanitize the console output of the machine under test. These are
 155  typically perl, awk or sed scripts that remove things in the kernel
 156  output that change each time the test is run and/or compiled.</DD>
 157 <DT>INIT_SCRIPT</DT>
 158 <DD>
 159 <P>a file of commands that is fed into the virtual machine's console in
 160  single user mode prior to starting the tests. This file will usually
 161  set up any eroute's and SADB entries that are required for the test.</P>
 162 <P>Lines beginning with # are skipped. Blank lines are skipped.
 163  Otherwise, a shell prompted is waited for each time (consisting of <CODE>
 164 \n#</CODE>) and then the command is sent. Note that the prompt is waited
 165  for before the command and not after, so completion of the last command
 166  in the script is not required. This is often used to invoke a program
 167  to monitor the system, e.g. <CODE>ipsec pf_key</CODE>.</P>
 168 </DD>
 169 <DT>RUN_SCRIPT</DT>
 170 <DD>
 171 <P>a file of commands that is fed into the virtual machine's console in
 172  single user mode, before the packets are sent. On single machine tests,
 173  this script doesn't provide any more power than INIT_SCRIPT, but is
 174  implemented for consistency's sake.</P>
 175 </DD>
 176 <DT>FINAL_SCRIPT</DT>
 177 <DD>
 178 <P>a file of commands that is fed into the virtual machine's console in
 179  single user mode after the final packet is sent. Similar to
 180  INIT_SCRIPT, above. If not specified, then the single command &quot;halt&quot; is
 181  sent. If specified, then the script should end with a halt command to
 182  nicely shutdown the UML.</P>
 183 </DD>
 184 <DT>CONSOLEDIFFDEBUG</DT>
 185 <DD>If set to &quot;true&quot; then the series of console fixups (see
 186  REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
 187  be set to &quot;false&quot;, or unset otherwise)</DD>
 188 <DT>NETJIGDEBUG</DT>
 189 <DD>If set to &quot;true&quot; then the series of console fixups (see
 190  REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
 191  be set to &quot;false&quot;, or unset otherwise)</DD>
 192 <DT>NETJIGTESTDEBUG</DT>
 193 <DD> If set to &quot;netjig&quot;, then the results of talking to the <CODE>
 194 uml_netjig</CODE> will be printed to stderr during the test. In
 195  addition, the jig will be invoked with --debug, which causes it to log
 196  its process ID, and wait 60 seconds before continuing. This can be used
 197  if you are trying to debug the <CODE>uml_netjig</CODE> program itself.</DD>
 198 <DT>HOSTTESTDEBUG</DT>
 199 <DD> If set to &quot;hosttest&quot;, then the results of taling to the consoles of
 200  the UMLs will be printed to stderr during the test.</DD>
 201 <DT>NETJIGWAITUSER</DT>
 202 <DD> If set to &quot;waituser&quot;, then the scripts will wait forever for user
 203  input before they shut the tests down. Use this is if you are debugging
 204  through the kernel.</DD>
 205 <DT>PACKETRATE</DT>
 206 <DD> A number, in miliseconds (default is 500ms) at which packets will
 207  be replayed by the netjig.</DD>
 208 </DL>
 209 <H2><A NAME="39_5">KLIPStest paramaters</A></H2>
 210 <P> The klipstest function starts a program (<CODE>
 211 testing/utils/uml_netjig/uml_netjig</CODE>) to setup a bunch of I/O
 212  sockets (that simulate network interfaces). It then exports the
 213  references to these sockets to the environment and invokes (using
 214  system()) a given script. It waits for the script to finish.</P>
 215
 216 <!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
 217 <P> The script invoked (<CODE>testing/utils/host-test.tcl</CODE>) is a
 218  TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
 219  to start the UML and configure it appropriately for the test. The
 220  configuration is done with the script given above for<VAR> INIT_SCRIPT</VAR>
 221 . The TCL script then forks, leaves the UML in the background and exits.
 222  uml_netjig continues. It then starts listening to the simulated network
 223  answering ARPs and inserting packets as appropriate.</P>
 224 <P> The klipstest function invokes <CODE>uml_netjig</CODE> with
 225  arguments to capture output from network interface(s) and insert
 226  packets as appropriate:</P>
 227 <DL>
 228 <DT>PUB_INPUT</DT>
 229 <DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
 230  public (encrypted) interface. (typically, eth1)</DD>
 231 <DT>PRIV_INPUT</DT>
 232 <DD>a pcap file to feed in on the private (plain-text) interface
 233  (typically, eth0).</DD>
 234 <DT>REF_PUB_OUTPUT</DT>
 235 <DD>a text file containing tcpdump output. Packets on the public (eth1)
 236  interface are captured to a<A HREF="http://www.tcpdump.org/"> pcap</A>
 237  file by <CODE>uml_netjig</CODE>. The klipstest function then uses
 238  tcpdump on the file to produce text output, which is compared to the
 239  file given.</DD>
 240 <DT>REF_PUB_FILTER</DT>
 241 <DD>a program that will filter the TCPDUMP output to do further
 242  processing. Defaults to &quot;cat&quot;.</DD>
 243 <DT>REF_PRIV_OUTPUT</DT>
 244 <DD>a text file containing tcpdump output. Packets on the private (eth0)
 245  interface are captured and compared after conversion by tcpdump, as
 246  with<VAR> REFPUBOUTPUT</VAR>.</DD>
 247 <DT>REF_PRIV_FILTER</DT>
 248 <DD>a program that will filter the TCPDUMP output to do further
 249  processing. Defaults to &quot;cat&quot;.</DD>
 250 <DT>EXITONEMPTY</DT>
 251 <DD>a flag for <CODE>uml_netjig</CODE>. It should contain
 252  &quot;--exitonempty&quot; of uml_netjig should exit when all of the input (<VAR>
 253 PUBINPUT</VAR>,<VAR>PRIVINPUT</VAR>) packets have been injected.</DD>
 254 <DT>ARPREPLY</DT>
 255 <DD>a flag for <CODE>uml_netjig</CODE>. It should contain &quot;--arpreply&quot;
 256  if <CODE>uml_netjig</CODE> should reply to ARP requests. One will
 257  typically set this to avoid having to fudge the ARP cache manually.</DD>
 258 <DT>TCPDUMPFLAGS</DT>
 259 <DD>a set of flags for the tcpdump used when converting captured output.
 260  Typical values will include &quot;-n&quot; to turn off DNS, and often &quot;-E&quot; to set
 261  the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
 262  &quot;-t&quot; flag (turn off timestamps) is provided automatically</DD>
 263 <DT>NETJIG_EXTRA</DT>
 264 <DD>additional comments to be sent to the netjig. This may arrange to
 265  record or create additional networks, or may toggle options.</DD>
 266 </DL>
 267 <H2><A NAME="39_6">mkinsttest paramaters</A></H2>
 268 <P> The basic concept of the <CODE>mkinsttest</CODE> test type is that
 269  it performs a &quot;make install&quot; to a temporary $DESTDIR. The resulting
 270  tree can then be examined to determine if it was done properly. The
 271  files can be uninstalled to determine if the file list was correct, or
 272  the contents of files can be examined more precisely.</P>
 273 <DL>
 274 <DT>INSTALL_FLAGS</DT>
 275 <DD>If set, then an install will be done. This provides the set of flags
 276  to provide for the install. The target to be used (usually &quot;install&quot;)
 277  must be among the flags.</DD>
 278 <DT>POSTINSTALL_SCRIPT</DT>
 279 <DD>If set, a script to run after initial &quot;make install&quot;. Two arguments
 280  are provided: an absolute path to the root of the FreeSWAN src tree,
 281  and an absolute path to the temporary installation area.</DD>
 282 <DT>INSTALL2_FLAGS</DT>
 283 <DD>If set, a second install will be done using these flags. Similarly
 284  to INSTALL_FLAGS, the target must be among the flags.</DD>
 285 <DT>UNINSTALL_FLAGS</DT>
 286 <DD>If set, an uninstall will be done using these flags. Similarly to
 287  INSTALL_FLAGS, the target (usually &quot;uninstall&quot;) must be among the
 288  flags.</DD>
 289 <DT>REF_FIND_f_l_OUTPUT</DT>
 290 <DD>If set, a <CODE>find $ROOT ( -type f -or -type -l )</CODE> will be
 291  done to get a list of a real files and symlinks. The resulting file
 292  will be compared to the file listed by this option.</DD>
 293 <DT>REF_FILE_CONTENTS</DT>
 294 <DD>If set, it should point to a file containing records for the form:
 295 <PRE>
 296
 297 <!--VARIABLE-->
 298 reffile</(null)>
 299 <!--VARIABLE-->
 300 samplefile</(null)>
 301 </PRE>
 302  one record per line. A diff between the provided reference file, and
 303  the sample file (located in the temporary installation root) will be
 304  done for each record.</DD>
 305 </DL>
 306 <H2><A NAME="39_7">rpm_build_install_test paramaters</A></H2>
 307 <P> The <CODE>rpm_build_install_test</CODE> type is to verify that the
 308  proper packing list is produced by &quot;make rpm&quot;, and that the mechanisms
 309  for building the kernel modules produce consistent results.</P>
 310 <DL>
 311 <DT>RPM_KERNEL_SOURCE</DT>
 312 <DD>Point to an extracted copy of the RedHat kernel source code.
 313  Variables from the environment may be used.</DD>
 314 <DT>REF_RPM_CONTENTS</DT>
 315 <DD>This is a file containing one record per line. Each record consists
 316  of a RPM name (may contain wildcards) and a filename to compare the
 317  contents to. The RPM will be located and a file list will be produced
 318  with rpm2cpio.</DD>
 319 </DL>
 320 <H2><A NAME="39_8">libtest paramaters</A></H2>
 321 <P> The libtest test is for testing library routines. The library file
 322  is expected to provided an <CODE>#ifdef</CODE> by the name of<VAR>
 323  library</VAR>
 324 <!--CODE_MAIN</CODE-->
 325 . The libtest type invokes the C compiler to compile this
 326  file, links it against <CODE>libfreeswan.a</CODE> (to resolve any other
 327  dependancies) and runs the test with the <CODE>-r</CODE> argument to
 328  invoke a regression test.</(null)></P>
 329 <P>The library test case is expected to do a self-test, exiting with
 330  status code 0 if everything is okay, and with non-zero otherwise. A
 331  core dump (exit code greater than 128) is noted specifically.</P>
 332 <P> Unlike other tests, there are no subdirectories required, or other
 333  parameters to set.</P>
 334 <H2 NAME="umlplutotest"><A NAME="39_9">umlplutotest paramaters</A></H2>
 335 <P> The umlplutotest function starts a pair of user mode line processes.
 336  This is a 2-host version of umlXhost. The &quot;EAST&quot; and &quot;WEST&quot; slots are
 337  defined.</P>
 338 <H2 NAME="umlXhost"><A NAME="39_10">umlXhost parameters</A></H2>
 339 <P> The umlXtest function starts an arbitrary number of user mode line
 340  processes.</P>
 341
 342 <!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
 343 <P> The script invoked (<CODE>testing/utils/Xhost-test.tcl</CODE>) is a
 344  TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
 345  to start each UML and configure it appropriately for the test. It then
 346  starts listening (using uml_netjig) to the simulated network answering
 347  ARPs and inserting packets as appropriate.</P>
 348 <P> umlXtest has a series of slots, each of which should be filled by a
 349  host. The list of slots is controlled by the variable, XHOST_LIST. This
 350  variable should be set to a space seperated list of slots. The former
 351  umlplutotest is now implemented as a variation of the umlXhost test,
 352  with XHOST_LIST=&quot;EAST WEST&quot;.</P>
 353 <P> For each host slot that is defined, a series of variables should be
 354  filled in, defining what configuration scripts to use for that host.</P>
 355 <P> The following are used to control the console input and output to
 356  the system. Where the string ${host} is present, the host slot should
 357  be filled in. I.e. for the two host system with XHOST_LIST=&quot;EAST WEST&quot;,
 358  then the variables: EAST_INIT_SCRIPT and WEST_INIT_SCRIPT will exist.</P>
 359 <DL>
 360 <DT>${host}HOST</DT>
 361 <DD>The name of the UML host which will fill this slot</DD>
 362 <DT>${host}_INIT_SCRIPT</DT>
 363 <DD>
 364 <P>a file of commands that is fed into the virtual machine's console in
 365  single user mode prior to starting the tests. This file will usually
 366  set up any eroute's and SADB entries that are required for the test.
 367  Similar to INIT_SCRIPT, above.</P>
 368 </DD>
 369 <DT>${host}_RUN_SCRIPT</DT>
 370 <DD>
 371 <P>a file of commands that is fed into the virtual machine's console in
 372  single user mode, before the packets are sent. This set of commands is
 373  run after all of the virtual machines are initialized. I.e. after
 374  EAST_INIT_SCRIPT<B> AND</B> WEST_INIT_SCRIPT. This script can therefore
 375  do things that require that all machines are properly configured.</P>
 376 </DD>
 377 <DT>${host}_RUN2_SCRIPT</DT>
 378 <DD>
 379 <P>a file of commands that is fed into the virtual machine's console in
 380  single user mode, after the packets are sent. This set of commands is
 381  run before any of the virtual machines have been shut down. (I.e.
 382  before EAST_FINAL_SCRIPT<B> AND</B> WEST_FINAL_SCRIPT.) This script can
 383  therefore catch post-activity status reports.</P>
 384 </DD>
 385 <DT>${host}_FINAL_SCRIPT</DT>
 386 <DD>
 387 <P>a file of commands that is fed into the virtual machine's console in
 388  single user mode after the final packet is sent. Similar to
 389  INIT_SCRIPT, above. If not specified, then the single command &quot;halt&quot; is
 390  sent. Note that when this script is run, the other virtual machines may
 391  already have been killed. If specified, then the script should end with
 392  a halt command to nicely shutdown the UML.</P>
 393 </DD>
 394 <DT>REF_${host}_CONSOLE_OUTPUT</DT>
 395 <DD>Similar to REF_CONSOLE_OUTPUT, above.</DD>
 396 </DL>
 397 <P>Some additional flags apply to all hosts:</P>
 398 <DL>
 399 <DT>REF_CONSOLE_FIXUPS</DT>
 400 <DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
 401  to sanitize the console output of the machine under test. These are
 402  typically perl, awk or sed scripts that remove things in the kernel
 403  output that change each time the test is run and/or compiled.</DD>
 404 </DL>
 405 <P> In addition to input to the console, the networks may have input fed
 406  to them:</P>
 407 <DL>
 408 <DT>EAST_INPUT/WEST_INPUT</DT>
 409 <DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
 410  private network side of each network. The &quot;EAST&quot; and &quot;WEST&quot; here refer
 411  to the networks, not the hosts.</DD>
 412 <DT>REF_PUB_FILTER</DT>
 413 <DD>a program that will filter the TCPDUMP output to do further
 414  processing. Defaults to &quot;cat&quot;.</DD>
 415 <DT>REF_EAST_FILTER/REF_WEST_FILTER</DT>
 416 <DD>a program that will filter the TCPDUMP output to do further
 417  processing. Defaults to &quot;cat&quot;.</DD>
 418 &lt;
 419 <DT>TCPDUMPFLAGS</DT>
 420 <DD>a set of flags for the tcpdump used when converting captured output.
 421  Typical values will include &quot;-n&quot; to turn off DNS, and often &quot;-E&quot; to set
 422  the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
 423  &quot;-t&quot; flag (turn off timestamps) is provided automatically</DD>
 424 <DT>REF_EAST_OUTPUT/REF_WEST_OUTPUT</DT>
 425 <DD>a text file containing tcpdump output. Packets on the private (eth0)
 426  interface are captured and compared after conversion by tcpdump, as
 427  with<VAR> REF_PUB_OUTPUT</VAR>.</DD>
 428 <P> There are two additional environment variables that may be set on
 429  the command line:</P>
 430 <DL>
 431 <DT> NETJIGVERBOSE=verbose export NETJIGVERBOSE</DT>
 432 <DD> If set, then the test output will be &quot;chatty&quot;, and let you know
 433  what commands it is running, and as packets are sent. Without it set,
 434  the output is limited to success/failure messages.</DD>
 435 <DT> NETJIGTESTDEBUG=netjig export NETJIGTESTDEBUG</DT>
 436 <DD> This will enable debugging of the communication with uml_netjig,
 437  and turn on debugging in this utility. This does not imply
 438  NETJIGVERBOSE.</DD>
 439 </DL>
 440 <DT> HOSTTESTDEBUG=hosttest export HOSTTESTDEBUG</DT>
 441 <DD> This will show all interactions with the user-mode-linux consoles</DD>
 442 </DL>
 443 <H2 NAME="kernelpatch"><A NAME="39_11">kernel_patch_test paramaters</A></H2>
 444 <P> The kernel_patch_test function takes some kernel source, copies it
 445  with lndir, and then applies the patch as produced by &quot;make
 446  kernelpatch&quot;.</P>
 447 <P> The following are used to control the input and output to the
 448  system:</P>
 449 <DL>
 450 <DT>KERNEL_NAME</DT>
 451 <DD>the kernel name, typically something like &quot;linus&quot; or &quot;rh&quot;</DD>
 452 <DT>KERNEL_VERSION</DT>
 453 <DD>the kernel version number, as in &quot;2.2&quot; or &quot;2.4&quot;.</DD>
 454 <DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
 455 <DD>This variable should set in the environment, probably in
 456  ~/freeswan-regress-env.sh. Examples of this variables would be
 457  KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
 458  an extracted copy of the kernel source in question.</DD>
 459 <DT>REF_PATCH_OUTPUT</DT>
 460 <DD>a copy of the patch output to compare against</DD>
 461 <DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
 462 <DD>If set to a non-empty string, then the patched kernel source is not
 463  removed at the end of the test. This will typically be set in the
 464  environment while debugging.</DD>
 465 </DL>
 466 <H2 NAME="modtest"><A NAME="39_12">module_compile paramaters</A></H2>
 467 <P> The module_compile test attempts to build the KLIPS module against a
 468  given set of kernel source. This is also done by the RPM tests, but in
 469  a very specific manner.</P>
 470 <P> There are two variations of this test - one where the kernel either
 471  doesn't need to be configured, or is already done, and tests were there
 472  is a local configuration file.</P>
 473 <P> Where the kernel doesn't need to be configured, the kernel source
 474  that is found is simply used. It may be a RedHat-style kernel, where
 475  one can cause it to configure itself via rhconfig.h-style definitions.
 476  Or, it may just be a kernel tree that has been configured.</P>
 477 <P> If the variable KERNEL_CONFIG_FILE is set, then a new directory is
 478  created for the kernel source. It is populated with lndir(1). The
 479  referenced file is then copied in as .config, and &quot;make oldconfig&quot; is
 480  used to configure the kernel. This resulting kernel is then used as the
 481  reference source.</P>
 482 <P> In all cases, the kernel source is found the same was for the
 483  kernelpatch test, i.e. via KERNEL_VERSION/KERNEL_NAME and
 484  KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC.</P>
 485 <P> Once there is kernel source, the module is compiled using the
 486  top-level &quot;make module&quot; target.</P>
 487 <P> The test is considered successful if an executable is found in
 488  OUTPUT/module/ipsec.o at the end of the test.</P>
 489 <DL>
 490 <DT>KERNEL_NAME</DT>
 491 <DD>the kernel name, typically something like &quot;linus&quot; or &quot;rh&quot;</DD>
 492 <DT>KERNEL_VERSION</DT>
 493 <DD>the kernel version number, as in &quot;2.2&quot; or &quot;2.4&quot;.</DD>
 494 <DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
 495 <DD>This variable should set in the environment, probably in
 496  ~/freeswan-regress-env.sh. Examples of this variables would be
 497  KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
 498  an extracted copy of the kernel source in question.</DD>
 499 <DT>KERNEL_CONFIG_FILE</DT>
 500 <DD>The configuration file for the kernel.</DD>
 501 <DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
 502 <DD>If set to a non-empty string, then the configured kernel source is
 503  not removed at the end of the test. This will typically be set in the
 504  environment while debugging.</DD>
 505 <DT>MODULE_DEF_INCLUDE</DT>
 506 <DD>The include file that will be used to configure the KLIPS module,
 507  and possibly the kernel source.</DD>
 508 </DL>
 509 <H1><A NAME="40">Current pitfalls</A></H1>
 510 <DL>
 511 <DT> &quot;tcpdump dissector&quot; not available.</DT>
 512 <DD> This is a non-fatal warning. If uml_netjig is invoked with the -t
 513  option, then it will attempt to use tcpdump's dissector to decode each
 514  packet that it processes. The dissector is presently not available, so
 515  this option it normally turned off at compile time. The dissector
 516  library will be released with tcpdump version 4.0.</DD>
 517 </DL>
 518 <HR>
 519 <A HREF="toc.html">Contents</A>
 520 <A HREF="umltesting.html">Previous</A>
 521 <A HREF="nightly.html">Next</A>
 522 </BODY>
 523 </HTML>