We need to take care of one loose end. The usage of the transports var- ies somewhat because of their differing configuration needs. In most
148 Chapter 7 UML Networking in Depth
cases, these differences are confined to the configuration string pro- vided to UML on the command line or to uml_mconsole. In the case of uml_switch, we also need to look at the invocation of the switch.
Despite the differences, there are some commonalities. The parameters to the device are separated by commas. Many parameters are optional; to exclude one, just specify it as an empty string. Trailing commas can be omitted. For example, a TUN/TAP interface that the uml_net helper will set up can look like this:
eth0=tuntap,,fd:fe:1:2:3:4,192.168.0.1
Leaving out the Ethernet MAC would make it look like this:
eth0=tuntap,,,192.168.0.1
Omitted parameters will be provided with default values. In the case above, the omitted MAC will be initialized as described below. The omitted TUN/TAP interface name will be determined by the uml_net helper when it configures the interface.
The transports that create an Ethernet device inside UML can take an Ethernet MAC in the device specification. If not specified, it will be assigned a MAC when it is first assigned an IP address. The MAC will be derived from the IP—the first two bytes are 0xfd and 0xfe, and the last four are the IP address. This makes the MAC as unique as the IP address. Normally, the MAC can be left out. However, when you want the UML instance to be able to use DHCP, you must specify a MAC because the device will not operate without one and it must have a MAC in order for the DHCP server to provide an IP address. When it is acceptable for the UML interface to not work until it is assigned an IP address, you can let the driver assign the MAC.
However, if the interface is already up before it is assigned an IP address, the driver cannot change the MAC address on its own. Some distributions enable interfaces like this. In this case, the MAC will end up as fd:fe:00:00:00:00. If you are running several UML instances, it is likely that these MACs will conflict, causing mysterious network failures. The easiest way to fix this problem is to provide the MAC on the command line. You can also take the interface down and bring it back up by hand. When you bring it back up, you should specify the IP address on the ifconfig command line. This will ensure that the driver knows the IP address when the interface is enabled, so it can be assigned a reasonable MAC.
Whenever there is a network interface on the host that the trans- port communicates through, such as a TUN/TAP or Ethertap device,
The UML Networking Transports 149
the IP address of that interface, the host-side IP, can be included. As we saw earlier in the chapter, when an IP address is specified in the device configuration, the driver will run the uml_net helper in order to set up the device on the host. When it is omitted, a preconfigured host device should be included in the configuration string.
As we have already seen, the configuration syntax for a device is identical whether it is being configured on the UML command line or being hot-plugged with an MConsole client.
TUN/TAP
The TUN/TAP configuration string comes in two forms, depending on whether you are assigning the UML interface a preconfigured host interface or whether you want the uml_net helper to create and config- ure the host interface.
In the first case, you specify
☞
tuntap☞
The host interface name☞
Optionally, the MAC of the UML interface For example:eth0=tuntap,my-uml-tap,fe:fd:1:2:3:4
or
eth0=tuntap,my-uml-tap
In the second case, you specify
☞
tuntap☞
An empty parameter, in place of the host interface name☞
Optionally, the MAC of the UML interface☞
The IP address of the host interface to be configured For example:eth0=tuntap,,fe:fd:1:2:3:4,192.168.0.1
or
150 Chapter 7 UML Networking in Depth
The three commas mean that parameters two and three (the host interface name and Ethernet MAC) are empty and will be assigned val- ues by the driver.
Ethertap
The Ethertap configuration string is nearly identical, except that the device type is ethertap and that you must specify a host interface name. When the host interface doesn’t exist and you provide an IP address, uml_net will configure that device. This example tells the driver to use a preconfigured Ethertap interface:
eth0=ethertap,tap0
This results in the uml_net helper creating and configuring a new Ethertap interface:
eth0=ethertap,tap0,,192.168.0.1
SLIP
The SLIP configuration is comparatively simple—only the IP address of the host SLIP device needs to be specified. It must be there since uml_net will always run in order to configure the SLIP interface. There is no possibility of specifying a MAC since the UML interface will not be an Ethernet device. This means that DHCP and other Ethernet protocols, such as ARP, can’t be used with SLIP.
eth0=slip,192.168.0.1
Slirp
The Slirp configuration requires
☞
slirp☞
Optionally, the MAC of the UML interface☞
The command line of the Slirp executableIf you decide to try this, you should probably first configure and run Slirp without UML. Once you can run it by hand, you can put the Slirp command line in the configuration string and it will work as it did before.
Adding the Slirp command line requires that it be transformed somewhat in order to not confuse the driver’s parser. First, the com- mand and its arguments should be separated by commas rather than
The UML Networking Transports 151
spaces. Second, any spaces embedded in an argument should be changed to underscores. However, in the normal case Slirp takes no arguments, and only the path to the Slirp executable needs to be specified.
If some arguments need to be provided, Slirp will read options from your ~/.sliprc. Putting the requisite information there will sim- plify the UML command line. It is also possible to pass the name of a wrapper script that will invoke slirp with the correct arguments. Multicast
Multicast is the simplest transport to configure, if you want the defaults:
eth0=mcast
The full configuration contains
☞
mcast☞
Optionally, the MAC of the UML interface☞
Optionally, the address of the multicast network☞
Optionally, the port to bind to in order to send and receive multi- cast packets☞
Optionally, the time to live (TTL) for transmitted packetsSpecifying the MAC is the same with mcast as with all the other transports.
The address determines which multicast group the UML instance will join. You can have multiple, simultaneous, mcast-based virtual networks by assigning the interfaces to different multicast groups. All IP addresses within the range 224.0.0.0 to 239.255.255.255 are multicast addresses. If a value isn’t specified, 239.192.168.1 will be used.
The TTL determines how far the packets will propagate.
☞
0: The packet will not leave the host.☞
1: The packet will not leave the local network and will not cross a router.☞
Less than 32: The packet will not leave the local organization.☞
Less than 64: The packet will not leave the region.☞
Less than 128: The packet will not leave the continent.152 Chapter 7 UML Networking in Depth
Obviously, the terms “local organization,” “region,” and “continent” are not well defined in terms of networking hardware, even if they are well-defined geographically, which they often aren’t. It is up to the router administrators to decide whether or not their equipment is on the border of one of these areas and configure it appropriately. Once configured, the routers will drop any multicast packets that have insuf- ficient TTLs to cross the border.
The default TTL is 1, so the packet can leave the host but not the local Ethernet.
The port should be specified if there are multiple UML instances on different multicast networks on the host so that instances on differ- ent networks are attached to different ports. The default port is 1102.
However, not all hosts provide multicast support. The CONFIG_IP_MULTICAST and CONFIG_IP_MROUTE (under “IP: Multi- cast router” in the kernel configuration) must be enabled. Without these, you’d see:
mcast_open: IP_ADD_MEMBERSHIP failed, error = 19 There appears not to be a multicast-capable network \ interface on the host.
eth0 should be configured in order to use the multicast \ transport.
uml_switch
The daemon transport differs from all the others in requiring a process to be started before the network will work. The process is uml_switch, which implements a virtual switch, as its name suggests. The simplest invocation is this:
host% uml_switch
uml_switch attached to unix socket '/tmp/uml.ctl'
The corresponding UML device configuration would be:
eth0=daemon
The defaults of both uml_switch and the UML driver are such that they will interoperate with each other. So, if you want a single switch on the host, the configurations above will work.
If you want multiple switches on the host, then all but one of them, and the UML instances that will connect to them, need to be configured differently. The switch and the UML instances communicate with data- grams over UNIX domain sockets. The default socket is /tmp/ uml.ctl, as the message from the switch indicates.
The UML Networking Transports 153
A different socket can be specified with:
host% uml_switch -unix /tmp/uml-2.ctl
In order to attach to this switch, the same socket must be provided to the UML network driver:
eth0=daemon,,unix,/tmp/uml-2.ctl
unix specifies the type of socket to use, and the following argument specifies the socket address. At this writing, only UNIX domain sockets are supported, but this is intended to extend to allowing communica- tion over IP sockets as well. In this case, the socket address would con- sist of an IP address or host name and a port number.
Some distributions (notably Debian) change the default location of the pipe used by uml_switch (to /var/run/uml-utilities/ uml_switch.ctl2 in Debian’s case). If you use the defaults as described above and there is no connection between the UML instance and the uml_switch process, you need to figure out where the uml_switch socket is and configure the UML interface to use it.
As I mentioned earlier, uml_switch normally acts as a switch, so that it remembers what Ethernet MACs it has seen on what ports and transmits packets only to the port that the UML instance with the des- tination MAC is attached to. This saves the switch from having to for- ward all packets to all its instances, and it also saves the UML instances from having to receive and parse them and discard all pack- ets not addressed to them.
uml_switch can be configured as a hub by using the -hub switch. In this case, all instances attached to it will see all packets on the net- work. This is sometimes useful when you want to sniff traffic between two UML instances from a third.
Normally, the switch provides an isolated virtual network, with no access to the host network. There is an option to have it connect to a preconfigured TUN/TAP device, in which case, that device will be another port on the switch, and packets will be forwarded to the host through it as appropriate. The command line would look like this:
uml_switch -tap switch-tap
switch-tap must be a TUN/TAP device that has already been created and configured as described in the TUN/TAP section earlier. Either bridging or routing, IP packet forwarding, and proxy arp should already be configured for this device.
154 Chapter 7 UML Networking in Depth
The full UML device configuration contains
☞
daemon☞
Optionally, the MAC of the UML interface☞
Optionally, the socket type, which currently must be unix☞
Optionally, the socket that the switch has attached topcap
The oddball transport, pcap, has a configuration unlike any of the oth- ers. The configuration comprises
☞
pcap☞
The host interface to sniff☞
A filter expression that determines which packets the UML inter- face will emit☞
Up to two options from the set promisc, nopromisc, optimize, and nooptimizeThe host interface may be the special string any. This will cause all host interfaces to be opened and sniffed.
The filter expression is a pcap filter program that specifies which packets should be selected.
The promisc flag determines whether libpcap will explicitly set the interface as promiscuous. The default is 1, so promisc has no effect, except for documentation. Even if nopromisc is specified, the pcap library may make the interface promiscuous for some other rea- son, such as being required to sniff the network.
The optimize and nooptimize flags control whether libpcap optimizes the filter expression.
Here is an example of configuring a pcap interface to emit only TCP packets to the UML interface:
eth0=pcap,eth0,tcp
This configures a second interface that would emit only non-TCP packets:
An Extended Example 155