/usr/share/doc/user-mode-linux-doc/html/UserModeLinux-HOWTO-6.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
 <TITLE>User Mode Linux HOWTO : Setting up the network</TITLE>
 <LINK HREF="UserModeLinux-HOWTO-7.html" REL=next>
 <LINK HREF="UserModeLinux-HOWTO-5.html" REL=previous>
 <LINK HREF="UserModeLinux-HOWTO.html#toc6" REL=contents>
</HEAD>
<BODY>
<A HREF="UserModeLinux-HOWTO-7.html">Next</A>
<A HREF="UserModeLinux-HOWTO-5.html">Previous</A>
<A HREF="UserModeLinux-HOWTO.html#toc6">Contents</A>
<HR>
<H2><A NAME="networking"></A> <A NAME="s6">6.</A> <A HREF="UserModeLinux-HOWTO.html#toc6">Setting up the network</A></H2>

<P> </P>
<P>This page describes how to set up the various transports and to
provide a UML instance with network access to the host, other machines
on the local net, and the rest of the net.</P>
<P> 
As of 2.4.5, UML networking has been completely redone to make it much 
easier to set up, fix bugs, and add new features.</P>
<P> 
There is a new helper, uml_net, which does the host setup that
requires root privileges.</P>
<P> 
There are currently five transport types available for a UML virtual
machine to exchange packets with other hosts:
<UL>
<LI>ethertap
</LI>
<LI>TUN/TAP
</LI>
<LI>Multicast
</LI>
<LI>a switch daemon
</LI>
<LI>slip
</LI>
<LI>slirp
</LI>
<LI>pcap
</LI>
</UL>

The TUN/TAP, ethertap, slip, and slirp transports allow a UML instance to
exchange packets with the host.  They may be directed to the host or
the host may just act as a router to provide access to other physical
or virtual machines.</P>
<P> 
The pcap transport is a synthetic read-only interface, using the libpcap
binary to collect packets from interfaces on the host and filter them.
This is useful for building preconfigured traffic monitors or sniffers.</P>
<P> 
The daemon and multicast transports provide a completely virtual
network to other virtual machines.  This network is completely
disconnected from the physical network unless one of the virtual
machines on it is acting as a gateway.</P>
<P> 
With so many host transports, which one should you use?  Here's when
you should use each one:
<UL>
<LI>ethertap - if you want access to the host networking and it is running
2.2
</LI>
<LI>TUN/TAP - if you want access to the host networking and it is running
2.4.  Also, the TUN/TAP transport is able to use a preconfigured
device, allowing it to avoid using the setuid uml_net helper, which
is a security advantage.
</LI>
<LI>Multicast - if you want a purely virtual network and you don't want to
set up anything but the UML
</LI>
<LI>a switch daemon - if you want a purely virtual network and you don't
mind running the daemon in order to get somewhat better performance
</LI>
<LI>slip - there is no particular reason to run the slip backend unless
ethertap and TUN/TAP are just not available for some reason
</LI>
<LI>slirp - if you don't have root access on the host to setup networking, 
or if you don't want to allocate an IP to your UML
</LI>
<LI>pcap - not much use for actual network connectivity, but great for 
monitoring traffic on the host
</LI>
</UL>

Ethertap is available on 2.4 and works fine.  TUN/TAP is preferred to
it because it has better performance and ethertap is officially
considered obsolete in 2.4.  Also, the root helper only needs to run
occasionally for TUN/TAP, rather than handling every packet, as it
does with ethertap.  This is a slight security advantage since it
provides fewer opportunities for a nasty UML user to somehow exploit
the helper's root privileges.</P>

<H2><A NAME="ss6.1">6.1</A> <A HREF="UserModeLinux-HOWTO.html#toc6.1">General setup</A>
</H2>

<P>First, you must have the virtual network enabled in your UML.  If are
running a prebuilt kernel from this site, everything is already enabled.
If you build the kernel yourself, under the &quot;Network device support&quot; menu,
enable &quot;Network device support&quot;, and then the three transports.</P>
<P> 
The next step is to provide a network device to the virtual machine.
This is done by describing it on the kernel command line.</P>
<P>The general format is 
<BLOCKQUOTE><CODE>
<PRE>
eth &lt;n> = &lt;transport> , &lt;transport args> 
</PRE>
</CODE></BLOCKQUOTE>

For example, a virtual ethernet device may be attached to a host ethertap
device as follows:
<BLOCKQUOTE><CODE>
<PRE>
eth0=ethertap,tap0,fe:fd:0:0:0:1,192.168.0.254
</PRE>
</CODE></BLOCKQUOTE>

This sets up eth0 inside the virtual machine to attach itself to the
host /dev/tap0, assigns it an ethernet address, and assigns the host
tap0 interface an IP address.  </P>

<P> 
Note that the IP address you assign to the host end of the tap device
must be different than the IP you assign to the eth device inside
UML.  If you are short on IPs and don't want to comsume two per
UML, then you can reuse the host's eth IP address for the host ends of
the tap devices.  Internally, the UMLs must still get unique IPs for
their eth devices.  You can also give the UMLs non-routable IPs
(192.168.x.x or 10.x.x.x) and have the host masquerade them.  This
will let outgoing connections work, but incoming connections won't
without more work, such as port forwarding from the host.</P>
<P> 
Also note that when you configure the host side of an interface, it is only
acting as a gateway.  It will respond to pings sent to it locally, but
is not useful to do that since it's a host interface.  You are not
talking to the UML when you ping that interface and get a response. </P>
<P> 
You can also add devices to a UML and remove them at runtime.  See 
the 
<A HREF="UserModeLinux-HOWTO-10.html#mconsole">The Management Console</A>  page for details.</P>
<P> 
The sections below describe this in more detail.</P>
<P> 
Once you've decided how you're going to set up the devices, you boot
UML, log in, configure the UML side of the devices, and set up routes
to the outside world.  At that point, you will be able to talk to any
other machines, physical or virtual, on the net.</P>
<P> 
If ifconfig inside UML fails and the network refuses to come up, run
'dmesg' to see what ended up in the kernel log.  That will usually
tell you what went wrong.</P>


<H2><A NAME="ss6.2">6.2</A> <A HREF="UserModeLinux-HOWTO.html#toc6.2">Userspace daemons</A>
</H2>

<P>You will likely need the setuid helper, or the switch daemon, or
both.  They are both installed with the RPM and deb, so if you've installed
either, you can skip the rest of this section.</P>
<P> 
If not, then you need to check them out of CVS,
build them, and install them.  The helper is uml_net, in CVS
/tools/uml_net, and the daemon is uml_switch, in CVS
/tools/uml_router.  They are both built with a plain 'make'.  Both
need to be installed in a directory that's in your path - /usr/bin is
recommend.  On top of that, uml_net needs to be setuid root.</P>


<H2><A NAME="ss6.3">6.3</A> <A HREF="UserModeLinux-HOWTO.html#toc6.3">Specifying ethernet addresses</A>
</H2>

<P>Below, you will see that the TUN/TAP, ethertap, and daemon interfaces
allow you to specify hardware addresses for the virtual ethernet
devices.  This is generally not necessary.  If you don't have a
specific reason to do it, you probably shouldn't.  If one is not
specified on the command line, the driver will assign one based on the
device IP address.  It will provide the address fe:fd:nn:nn:nn:nn
where nn.nn.nn.nn is the device IP address.  This is nearly always
sufficient to guarantee a unique hardware address for the device.  A
couple of exceptions are:
<UL>
<LI>Another set of virtual ethernet devices are on the same network and
they are assigned hardware addresses using a different scheme which
may conflict with the UML IP address-based scheme
</LI>
<LI>You aren't going to use the device for IP networking, so you don't
assign the device an IP address
</LI>
</UL>

If you let the driver provide the hardware address, you should make sure
that the device IP address is known before the interface is brought
up.  So, inside UML, this will guarantee that:
<BLOCKQUOTE><CODE>
<PRE>
UML# 
ifconfig eth0 192.168.0.250 up
</PRE>
</CODE></BLOCKQUOTE>

If you decide to assign the hardware address yourself, make sure that
the first byte of the address is even.  Addresses with an odd first byte
are broadcast addresses, which you don't want assigned to a device.</P>


<H2><A NAME="ss6.4">6.4</A> <A HREF="UserModeLinux-HOWTO.html#toc6.4">UML interface setup</A>
</H2>

<P>Once the network devices have been described on the command line, you
should boot UML and log in.</P>
<P> 
The first thing to do is bring the interface up:
<BLOCKQUOTE><CODE>
<PRE>
UML# ifconfig ethn ip-address up
</PRE>
</CODE></BLOCKQUOTE>

You should be able to ping the host at this point.</P>
<P> 
To reach the rest of the world, you should set a default route to the
host:
<BLOCKQUOTE><CODE>
<PRE>
UML# route add default gw host ip
</PRE>
</CODE></BLOCKQUOTE>

Again, with host ip of 192.168.0.4:
<BLOCKQUOTE><CODE>
<PRE>
UML# route add default gw 192.168.0.4
</PRE>
</CODE></BLOCKQUOTE>

This page used to recommend setting a network route to your local
net.  This is wrong, because it will cause UML to try to figure out
hardware addresses of the local machines by arping on the interface to
the host.  Since that interface is basically a single strand of
ethernet with two nodes on it (UML and the host) and arp requests
don't cross networks, they will fail to elicit any responses.  So,
what you want is for UML to just blindly throw all packets at the host
and let it figure out what to do with them, which is what leaving out
the network route and adding the default route does.</P>
<P> 
Note: If you can't communicate with other hosts on your physical
ethernet, it's probably because of a network route that's
automatically set up.  If you run 'route -n' and see a route that
looks like this:
<BLOCKQUOTE><CODE>
<PRE>
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0      0   eth0
</PRE>
</CODE></BLOCKQUOTE>

with a mask that's not 255.255.255.255, then replace it with a route
to your host:
<BLOCKQUOTE><CODE>
<PRE>
UML# 
route del -net 192.168.0.0 dev eth0 netmask 255.255.255.0
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
UML# 
route add -host 192.168.0.4 dev eth0
</PRE>
</CODE></BLOCKQUOTE>

This, plus the default route to the host, will allow UML to exchange
packets with any machine on your ethernet.</P>


<H2><A NAME="ss6.5">6.5</A> <A HREF="UserModeLinux-HOWTO.html#toc6.5">Multicast</A>
</H2>

<P>The simplest way to set up a virtual network between multiple UMLs is
to use the mcast transport.  This was written by Harald Welte and is
present in UML version 2.4.5-5um and later.  Your system must have
multicast enabled in the kernel and there must be a multicast-capable
network device on the host.  Normally, this is eth0, but if there is
no ethernet card on the host, then you will likely get strange error
messages when you bring the device up inside UML.</P>
<P> 
To use it, run two UMLs with 
<BLOCKQUOTE><CODE>
<PRE>
 eth0=mcast
</PRE>
</CODE></BLOCKQUOTE>

on their command lines.  Log in, configure the ethernet device in each
machine with different IP addresses:
<BLOCKQUOTE><CODE>
<PRE>
UML1# ifconfig eth0 192.168.0.254
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
UML2# ifconfig eth0 192.168.0.253
</PRE>
</CODE></BLOCKQUOTE>

and they should be able to talk to each other.</P>
<P> 
The full set of command line options for this transport are
<BLOCKQUOTE><CODE>
<PRE>
 
ethn=mcast,ethernet address,multicast
address,multicast port,ttl
</PRE>
</CODE></BLOCKQUOTE>

Harald's original README is 
<A HREF="http://user-mode-linux.sourceforge.net/text/mcast.txt">here</A>  and explains
these in detail, as well as some other issues.</P>


<H2><A NAME="ss6.6">6.6</A> <A HREF="UserModeLinux-HOWTO.html#toc6.6">TUN/TAP with the uml_net helper</A>
</H2>

<P>TUN/TAP is the preferred mechanism on 2.4 to exchange packets with the
host.  The TUN/TAP backend has been in UML since 2.4.9-3um.</P>
<P> 
The easiest way to get up and running is to let the setuid uml_net
helper do the host setup for you.  This involves insmod-ing the tun.o
module if necessary, configuring the device, and setting up IP
forwarding, routing, and proxy arp.  If you are new to UML networking,
do this first.  If you're concerned about the security implications of
the setuid helper, use it to get up and running, then read the next
section to see how to have UML use a preconfigured tap device, which
avoids the use of uml_net.</P>
<P> 
If you specify an IP address for the host side of the device, the
uml_net helper will do all necessary setup on the host - the only
requirement is that TUN/TAP be available, either built in to the host
kernel or as the tun.o module.</P>
<P>The format of the command line switch to attach a device to a TUN/TAP device
is 
<BLOCKQUOTE><CODE>
<PRE>
eth &lt;n> =tuntap,,, &lt;host IP address> 
</PRE>
</CODE></BLOCKQUOTE>

For example, this argument will attach the UML's eth0 to
the next available tap device, assign the IP address 
192.168.0.254 to the host side of the tap device, and
assign an ethernet address to it based on the IP address assigned to
it by ifconfig inside UML.
<BLOCKQUOTE><CODE>
<PRE>
eth0=tuntap,,,192.168.0.254
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P> 
If you using the uml_net helper to set up the host side of the
networking, as in this example, note that changing the UML IP address
will cause uml_net to change the host routing and arping to match.
This is one reason you should not be using uml_net if there is any
possibility that the user inside the UML may be unfriendly.  This
feature is convenient, but can be used to make the UML pretend to be
something like your name server or mail server, and the host will
steal packets intended for those servers and forward them to the UML.
See the next section for setting up networking in a secure manner.</P>
<P> 
There are a couple potential problems with running the TUN/TAP
transport on a 2.4 host kernel
<UL>
<LI>TUN/TAP seems not to work on 2.4.3 and earlier.  Upgrade the host
kernel or use the ethertap transport.
</LI>
<LI>With an upgraded kernel, TUN/TAP may fail with 
<BLOCKQUOTE><CODE>
<PRE>
File descriptor in bad state
</PRE>
</CODE></BLOCKQUOTE>

This is due to a header mismatch between the upgraded kernel and the
kernel that was originally installed on the machine.  The fix is to
make sure that /usr/src/linux points to the headers for the running kernel.
</LI>
</UL>

These were pointed out by 
<A HREF="timro at trkr dot net">Tim Robinson</A> 
in  
<A HREF="http://www.geocrawler.com/lists/3/SourceForge/597/0/">http://www.geocrawler.com/lists/3/SourceForge/597/0/</A> name="this uml-user post"> .</P>


<H2><A NAME="ss6.7">6.7</A> <A HREF="UserModeLinux-HOWTO.html#toc6.7">TUN/TAP with a preconfigured tap device</A>
</H2>

<P>If you prefer not to have UML use uml_net (which is somewhat
insecure), with UML 2.4.17-11, you can set up a TUN/TAP device
beforehand.  The setup needs to be done as root, but once that's done,
there is no need for root assistance.  Setting up the device is done
as follows: 
<UL>
<LI>Create the device with tunctl (available from the UML utilities
tarball)


<BLOCKQUOTE><CODE>
<PRE>
host#  tunctl -u uid
</PRE>
</CODE></BLOCKQUOTE>

where uid is the user id or username that UML will be run as.
This will tell you what device was created.
</LI>
<LI>Configure the device IP (change IP addresses and device name to suit)


<BLOCKQUOTE><CODE>
<PRE>
host#  ifconfig tap0 192.168.0.254 up
</PRE>
</CODE></BLOCKQUOTE>

</LI>
<LI>Set up routing and arping if desired - this is my recipe, there are
other ways of doing the same thing
<BLOCKQUOTE><CODE>
<PRE>
host#  
bash -c 'echo 1 &gt; /proc/sys/net/ipv4/ip_forward'
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
route add -host 192.168.0.253 dev tap0
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
bash -c 'echo 1 &gt; /proc/sys/net/ipv4/conf/tap0/proxy_arp'
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
arp -Ds 192.168.0.253 eth0 pub
</PRE>
</CODE></BLOCKQUOTE>

Note that this must be done every time the host boots - this
configuration is not stored across host reboots.  So, it's probably a
good idea to stick it in an rc file.  An even better idea would be a
little utility which reads the information from a config file and sets
up devices at boot time.
</LI>
<LI>Rather than using up two IPs and ARPing for one of them, you can also 
provide direct access to your LAN by the UML by using a bridge.
<BLOCKQUOTE><CODE>
<PRE>
host#  
brctl addbr br0
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
ifconfig eth0 0.0.0.0 promisc up
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
ifconfig tap0 0.0.0.0 promisc up
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
ifconfig br0 192.168.0.1 netmask 255.255.255.0 up
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
brctl stp br0 off
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
brctl setfd br0 1
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
brctl sethello br0 1
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
brctl addif br0 eth0
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
brctl addif br0 tap0
</PRE>
</CODE></BLOCKQUOTE>

Note that 'br0' should be setup using ifconfig with the existing IP 
address of eth0, as eth0 no longer has its own IP.
</LI>
<LI><P> 
Also, the /dev/net/tun device must be writable by the user running UML
in order for the UML to use the device that's been configured for it.
The simplest thing to do is
<BLOCKQUOTE><CODE>
<PRE>
host#  chmod 666 /dev/net/tun
</PRE>
</CODE></BLOCKQUOTE>

Making it world-writeable looks bad, but it seems not to be
exploitable as a security hole.  However, it does allow anyone to
create useless tap devices (useless because they can't configure
them), which is a DOS attack.  A somewhat more secure alternative
would to be to create a group containing all the users who have
preconfigured tap devices and chgrp /dev/net/tun to that group with
mode 664 or 660.</P>

</LI>
<LI>Once the device is set up, run UML with 
<BLOCKQUOTE><CODE>
<PRE>
 eth0=tuntap,devicename
</PRE>
</CODE></BLOCKQUOTE>
 i.e. 
<BLOCKQUOTE><CODE>
<PRE>
 eth0=tuntap,tap0
</PRE>
</CODE></BLOCKQUOTE>
 on the command line (or do it with
the mconsole config command).
</LI>
<LI>Bring the eth device up in UML and you're in business.
</LI>
</UL>

If you don't want that tap device any more, you can make it
non-persistent with 
<BLOCKQUOTE><CODE>
<PRE>
host#  tunctl -d tap device
</PRE>
</CODE></BLOCKQUOTE>

Finally, tunctl has a -b (for brief mode) switch which causes it to
output only the name of the tap device it created.  This makes it
suitable for capture by a script:
<BLOCKQUOTE><CODE>
<PRE>
host#  TAP=`tunctl -u 1000 -b`
</PRE>
</CODE></BLOCKQUOTE>
</P>


<H2><A NAME="ss6.8">6.8</A> <A HREF="UserModeLinux-HOWTO.html#toc6.8">Ethertap</A>
</H2>

<P>Ethertap is the general mechanism on 2.2 for userspace processes to
exchange packets with the kernel.</P>
<P> </P>
<P>To use this transport, you need to describe the virtual network
device on the UML command line.  The general format for this is
<BLOCKQUOTE><CODE>
<PRE>
eth &lt;n> =ethertap, &lt;device> , &lt;ethernet address> , &lt;host IP address> 
</PRE>
</CODE></BLOCKQUOTE>

So, the previous example
<BLOCKQUOTE><CODE>
<PRE>
eth0=ethertap,tap0,fe:fd:0:0:0:1,192.168.0.254
</PRE>
</CODE></BLOCKQUOTE>

attaches the UML eth0 device to the host 
/dev/tap0, assigns it the
ethernet address fe:fd:0:0:0:1, and assigns the IP address
192.168.0.254 to the host side of the tap device.</P>

<P> 
The tap device is mandatory, but the others are optional.  If the
ethernet address is omitted, one will be assigned to it.</P>
<P> 
The presence of the tap IP address will cause the helper to run and do
whatever host setup is needed to allow the virtual machine to
communicate with the outside world.  If you're not sure you know what
you're doing, this is the way to go.</P>
<P> 
If it is absent, then you must configure the tap device and whatever
arping and routing you will need on the host.  However, even in this
case, the uml_net helper still needs to be in your path and it must be
setuid root if you're not running UML as root.  This is because the
tap device doesn't support SIGIO, which UML needs in order to use
something as a source of input.  So, the helper is used as a
convenient asynchronous IO thread.</P>
<P>If you're using the uml_net helper, you can ignore the following host
setup - uml_net will do it for you.  You just need to make sure you
have ethertap available, either built in to the host kernel or
available as a module.</P>
<P> 
If you want to set things up yourself, you need to make
sure that the appropriate /dev entry exists.  If it doesn't, become
root and create it as follows (the $[ ... ] is bash syntax for adding 16 to
the minor number) :
<BLOCKQUOTE><CODE>
<PRE>
mknod /dev/tap &lt;minor>  c 36 $[  &lt;minor>  + 16 ]
</PRE>
</CODE></BLOCKQUOTE>

For example, this is how to create /dev/tap0:
<BLOCKQUOTE><CODE>
<PRE>
mknod /dev/tap0 c 36 $[ 0 + 16 ]
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>You also need to make sure that the host kernel has ethertap support.
If ethertap is enabled as a module, you apparently need to insmod
ethertap once for each ethertap device you want to enable.  So, 
<BLOCKQUOTE><CODE>
<PRE>
host#  
insmod ethertap
</PRE>
</CODE></BLOCKQUOTE>

will give you the tap0 interface.  To get the tap1 interface, you need
to run
<BLOCKQUOTE><CODE>
<PRE>
host#  
insmod ethertap unit=1 -o ethertap1
</PRE>
</CODE></BLOCKQUOTE>
</P>



<H2><A NAME="ss6.9">6.9</A> <A HREF="UserModeLinux-HOWTO.html#toc6.9">The switch daemon</A>
</H2>

<P><B>Note</B>: This is the daemon formerly known as uml_router, but
which was renamed so the network weenies of the world would stop
growling at me.</P>
<P> 
The switch daemon, uml_switch, provides a mechanism for creating a
totally virtual network.  By default, it provides no connection to the
host network (but see -tap, below).</P>
<P> 
The first thing you need to do is run the daemon.  Running it with no
arguments will make it listen on a default unix domain socket.</P>
<P> 
If you want it to listen on a different socket, use
<BLOCKQUOTE><CODE>
<PRE>
 -unix socket
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>If you want it to act as a hub rather than a switch, use
<BLOCKQUOTE><CODE>
<PRE>
 -hub
</PRE>
</CODE></BLOCKQUOTE>

If you're planning on putting it in hub mode so you can sniff UML
traffic from a tap device on the host, it appears that you need to
assign the tap an IP address before you'll see any packets on it.</P>
<P> 
If you want the switch to be connected to host networking (allowing the
umls to get access to the outside world through the host), use
<BLOCKQUOTE><CODE>
<PRE>
 -tap tap0
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P> 
Note that the tap device must be preconfigured (see &quot;TUN/TAP with a
preconfigured tap device&quot;, above).  If you're using a different tap
device than tap0, specify that instead of tap0.</P>
<P> 
uml_switch can be backgrounded as follows
<BLOCKQUOTE><CODE>
<PRE>
host% 
uml_switch [ options ] &lt; /dev/null &gt; /dev/null
</PRE>
</CODE></BLOCKQUOTE>

The reason it doesn't background by default is that it listens to
stdin for EOF.  When it sees that, it exits.</P>
<P> 
The general format of the kernel command line switch is
<BLOCKQUOTE><CODE>
<PRE>
 
ethn=daemon,ethernet address,socket type,socket
</PRE>
</CODE></BLOCKQUOTE>

You can leave off everything except the 'daemon'.  You only need to
specify the ethernet address if the one that will be assigned to it
isn't acceptable for some reason.  The rest of the arguments describe
how to communicate with the daemon.  You should only specify them if
you told the daemon to use different sockets than the default.  So, if
you ran the daemon with no arguments, running the UML on the same
machine with 
<BLOCKQUOTE><CODE>
<PRE>
 
eth0=daemon
</PRE>
</CODE></BLOCKQUOTE>

will cause the eth0 driver to attach itself to the daemon correctly.
The socket argument is the filename of a Unix domain socket which is
used for communications between uml_switch and the UMLs on its network.
If you do specify a different socket from the default, which you will
need to do if you want multiple, separate uml_switch networks on the
host, you need to make sure that you name the same path for the socket
on both the uml_switch and UML command lines.</P>
<P> 
Currently the only supported value for the socket type is &quot;unix&quot;.</P>


<H2><A NAME="ss6.10">6.10</A> <A HREF="UserModeLinux-HOWTO.html#toc6.10">Slip</A>
</H2>

<P>Slip is another, less general, mechanism for a process to communicate
with the host networking.  In contrast to the ethertap interface,
which exchanges ethernet frames with the host and can be used to
transport any higher-level protocol, it can only be used to transport
IP.</P>
<P> 
The general format of the command line switch is
<BLOCKQUOTE><CODE>
<PRE>
 
ethn=slip,slip IP
</PRE>
</CODE></BLOCKQUOTE>

The slip IP argument is the IP address that will be assigned to the
host end of the slip device.  If it is specified, the helper will run
and will set up the host so that the virtual machine can reach it and
the rest of the network.</P>
<P> 
There are some oddities with this interface that you should be aware
of.  You should only specify one slip device on a given virtual
machine, and its name inside UML will be 'umn', not 'eth0' or whatever
you specified on the command line.  These problems will be fixed at some point.</P>


<H2><A NAME="ss6.11">6.11</A> <A HREF="UserModeLinux-HOWTO.html#toc6.11">Slirp</A>
</H2>

<P>slirp uses an external program, usually /usr/bin/slirp, to provide IP
only networking connectivity through the host. This is similar to IP
masquerading with a firewall, although the translation is performed in
user-space, rather than by the kernel.  As slirp does not set up any
interfaces on the host, or changes routing, slirp does not require
root access or setuid binaries on the host.</P>
<P> 
The general format of the command line switch for slirp is:
<BLOCKQUOTE><CODE>
<PRE>
 
ethn=slirp,ethernet address,slirp path
</PRE>
</CODE></BLOCKQUOTE>

The ethernet address is optional, as UML will set up the interface
with an ethernet address based upon the initial IP address of the 
interface.  The slirp path is generally /usr/bin/slirp, although it
will depend on distribution.</P>
<P> 
The slirp program can have a number of options passed to the command line
and we can't add them to the UML command line, as they will be parsed
incorrectly.  Instead, a wrapper shell script can be written or the options
inserted into the &nbsp;/.slirprc file.  More information on all of the slirp
options can be found in its man pages.</P>
<P> 
The eth0 interface on UML should be set up with the IP 10.2.0.15, 
although you can use anything as long as it is not used by a network you 
will be connecting to. The default route on UML should be set to use 
'eth0' without a gateway IP:
<BLOCKQUOTE><CODE>
<PRE>
UML# 
route add default dev eth0
</PRE>
</CODE></BLOCKQUOTE>

slirp provides a number of useful IP addresses which can be used by 
UML, such as 10.0.2.3 which is an alias for the DNS server specified in 
/etc/resolv.conf on the host or the IP given in the 'dns' option for slirp.</P>
<P> 
Even with a baudrate setting higher than 115200, the slirp connection 
is limited to 115200. If you need it to go faster, the slirp binary 
needs to be compiled with FULL_BOLT defined in config.h.</P>


<H2><A NAME="ss6.12">6.12</A> <A HREF="UserModeLinux-HOWTO.html#toc6.12">pcap</A>
</H2>

<P>The pcap transport is attached to a UML ethernet device on the command 
line or with uml_mconsole with the following syntax:
<BLOCKQUOTE><CODE>
<PRE>
 
ethn=pcap,host interface,filter
expression,option1,option2 
</PRE>
</CODE></BLOCKQUOTE>

The expression and options are optional.</P>
<P> 
The interface is whatever network device on the host you want to sniff.
The expression is a pcap filter expression, which is also what tcpdump
uses, so if you know how to specify tcpdump filters, you will use the
same expressions here.  The options are up to two of 'promisc',
'nopromisc', 'optimize', 'nooptimize'. 'promisc' and 'nopromisc'
control whether pcap puts the host interface into promiscuous
mode. 'optimize' and 'nooptimize' control whether the pcap expression
optimizer is used. </P>
<P> 
Example:
<BLOCKQUOTE><CODE>
<PRE>
 
eth0=pcap,eth0,tcp

eth1=pcap,eth0,!tcp
</PRE>
</CODE></BLOCKQUOTE>

will cause the UML eth0 to emit all tcp packets on the host eth0 and the
UML eth1 to emit all non-tcp packets on the host eth0.</P>


<H2><A NAME="ss6.13">6.13</A> <A HREF="UserModeLinux-HOWTO.html#toc6.13">Setting up the host yourself</A>
</H2>

<P>If you don't specify an address for the host side of the ethertap or
slip device, UML won't do any setup on the host.  So this is what is
needed to get things working (the examples use a host-side IP of
192.168.0.251 and a UML-side IP of 192.168.0.250 - adjust to suit your
own network):
<UL>
<LI>The device needs to be configured with its IP address.  Tap devices
are also configured with an mtu of 1484.  Slip devices are configured
with a point-to-point address pointing at the UML ip address.
<BLOCKQUOTE><CODE>
<PRE>
host#  ifconfig tap0 arp mtu 1484 192.168.0.251 up
</PRE>
</CODE></BLOCKQUOTE>

<BLOCKQUOTE><CODE>
<PRE>
host#  
ifconfig sl0 192.168.0.251 pointopoint 192.168.0.250 up
</PRE>
</CODE></BLOCKQUOTE>

</LI>
<LI>If a tap device is being set up, a route is set to the UML IP.
<BLOCKQUOTE><CODE>
<PRE>
UML# route add -host 192.168.0.250 gw 192.168.0.251
</PRE>
</CODE></BLOCKQUOTE>

</LI>
<LI>To allow other hosts on your network to see the virtual machine, proxy
arp is set up for it.
<BLOCKQUOTE><CODE>
<PRE>
host#  arp -Ds 192.168.0.250 eth0 pub
</PRE>
</CODE></BLOCKQUOTE>

</LI>
<LI>Finally, the host is set up to route packets.
<BLOCKQUOTE><CODE>
<PRE>
host#  echo 1 &gt; /proc/sys/net/ipv4/ip_forward
</PRE>
</CODE></BLOCKQUOTE>

</LI>
</UL>
</P>








<HR>
<A HREF="UserModeLinux-HOWTO-7.html">Next</A>
<A HREF="UserModeLinux-HOWTO-5.html">Previous</A>
<A HREF="UserModeLinux-HOWTO.html#toc6">Contents</A>
</BODY>
</HTML>
user-mode-linux-doc 20060501-1 / usr / share / doc / user-mode-linux-doc / html / UserModeLinux-HOWTO-6.html
