User mode linux is a way to compile a linux kernel such that it can run as a process in another linux system (potentially as a *BSD or Windows process later). See http://user-mode-linux.sourceforge.net/
UML is a good platform for testing and experimenting with FreeS/WAN. It allows several network nodes to be simulated on a single machine. Creating, configuring, installing, monitoring, and controling these nodes is generally easier and easier to script with UML than real hardware.
You'll need about 500Mb of disk space for a full sunrise-east-west-sunset setup. You can possibly get this down by 130Mb if you remove the sunrise/sunset kernel build. If you just want to run, then you can even remove the east/west kernel build.
Nothing need be done as super user. In a couple of steps, we note where super user is required to install commands in system-wide directories, but ~/bin could be used instead. UML seems to use a system-wide /tmp/uml directory so different users may interfere with one another. Later UMLs use ~/.uml instead, so multiple users running UML tests should not be a problem, but note that a single user running the UML tests will only be able run one set. Further, UMLs sometimes get stuck and hang around. These "zombies" (most will actually be in the "T" state in the process table) will interfere with subsequent tests.
As of 2003/3/1, the Light-Weight Resolver is used by pluto. This requires that BIND9 be running. It also requires that BIND9 development libraries be present in the build environment. The DNSSEC code is only truly functional in BIND9 snapshots. The library code could be 9.2.2, we believe. We are using BIND9 20021115 snapshot code from ftp://ftp.isc.org/isc/bind9/snapshots.
FreeS/WAN may well require a newer BIND than is on your system. Many distributions have moved to BIND9.2.2 recently due to a security advisory. BIND is five components.
The only piece that we need for *building* is #4. That's the only part that has to be on the build host. What is the difference between resolver and util libs? If you want to edit testing/baseconfigs/all/etc/bind, you'll need a snapshot version. The resolver library contains the resolver. FreeS/WAN has its own copy of that in lib/liblwres.
cd /c2/kernel
tar xzvf ../download/pub/linux/kernel/v2.4/linux-2.4.19.tar.gz
mkdir -p /c2/user-mode-linux/basic-root
cd /c2/user-mode-linux/basic-root
tar xzvf ../download/umlfreeroot-15.1.tar.gz
mkdir -p /c2/freeswan/sandbox
cd /c2/freeswan/sandbox
tar xzvf ../download/snapshot.tar.gz
./configure
make
./configure
make
# Need to be superuser to install in system directories.
# Installing in ~/bin would be an alternative.
su -c "make install"
cd tools
make all
# Need to be superuser to install in system directories.
# Installing in ~/bin would be an alternative.
su -c "make install BIN_DIR=/usr/local/bin"
cd /c2/freeswan/sandbox/freeswan-1.97/testing/utils
cp umlsetup-sample.sh ../../umlsetup.sh
cd $TESTINGROOT/utils
sh make-uml.sh
It will grind for awhile. If there are errors it will bail.
If so, run it under "script" and send the output to bugs@lists.freeswan.org.
for i in sunrise sunset east west
do
xterm -name $i -title $i -e $POOLSPACE/$i/start.sh &
done
With User-Mode-Linux, you can debug the kernel using GDB.
See
Typically, one will want to address a test case for a failing situation. Running GDB from Emacs, or from other front ends is possible. First start GDB.
Tell it to open the UMLPOOL/swan/linux program.
Note the PID of GDB:
marajade-[projects/freeswan/mgmt/planning] mcr 1029 %ps ax | grep gdb 1659 pts/9 SN 0:00 /usr/bin/gdb -fullname -cd /mara4/freeswan/kernpatch/UMLPOOL/swan/ linux
Set the following in the environment:
UML_east_OPT="debug gdb-pid=1659"
Then start the user-mode-linux in the test scheme you wish:
marajade-[kernpatch/testing/klips/east-icmp-02] mcr 1220 %../../utils/runme.shThe user-mode-linux will stop on boot, giving you a chance to attach to the process:
(gdb) file linux Reading symbols from linux...done. (gdb) attach 1 Attaching to program: /mara4/freeswan/kernpatch/UMLPOOL/swan/linux, process 1 0xa0118bc1 in kill () at hostfs_kern.c:770
At this point, break points should be created as appropriate.
If you are running a standard test, after all the packets are sent, the UML will be shutdown. This can cause problems, because the UML may get terminated while you are debugging.
The environment variable NETJIGWAITUSER
can be set to "waituser".
If so, then the testing system will prompt before exiting the test.
uml_netjig can be compiled with a built-in tcpdump. This uses not-yet-released
code from www.tcpdump.org.
Please see the instructions in testing/utils/uml_netjig/Makefile
.