|  |  | 
|  | menu "UML Network Devices" | 
|  | depends on NET | 
|  |  | 
|  | # UML virtual driver | 
|  | config UML_NET | 
|  | bool "Virtual network device" | 
|  | help | 
|  | While the User-Mode port cannot directly talk to any physical | 
|  | hardware devices, this choice and the following transport options | 
|  | provide one or more virtual network devices through which the UML | 
|  | kernels can talk to each other, the host, and with the host's help, | 
|  | machines on the outside world. | 
|  |  | 
|  | For more information, including explanations of the networking and | 
|  | sample configurations, see | 
|  | <http://user-mode-linux.sourceforge.net/old/networking.html>. | 
|  |  | 
|  | If you'd like to be able to enable networking in the User-Mode | 
|  | linux environment, say Y; otherwise say N.  Note that you must | 
|  | enable at least one of the following transport options to actually | 
|  | make use of UML networking. | 
|  |  | 
|  | config UML_NET_ETHERTAP | 
|  | bool "Ethertap transport" | 
|  | depends on UML_NET | 
|  | help | 
|  | The Ethertap User-Mode Linux network transport allows a single | 
|  | running UML to exchange packets with its host over one of the | 
|  | host's Ethertap devices, such as /dev/tap0.  Additional running | 
|  | UMLs can use additional Ethertap devices, one per running UML. | 
|  | While the UML believes it's on a (multi-device, broadcast) virtual | 
|  | Ethernet network, it's in fact communicating over a point-to-point | 
|  | link with the host. | 
|  |  | 
|  | To use this, your host kernel must have support for Ethertap | 
|  | devices.  Also, if your host kernel is 2.4.x, it must have | 
|  | CONFIG_NETLINK_DEV configured as Y or M. | 
|  |  | 
|  | For more information, see | 
|  | <http://user-mode-linux.sourceforge.net/old/networking.html>  That site | 
|  | has examples of the UML command line to use to enable Ethertap | 
|  | networking. | 
|  |  | 
|  | If you'd like to set up an IP network with the host and/or the | 
|  | outside world, say Y to this, the Daemon Transport and/or the | 
|  | Slip Transport.  You'll need at least one of them, but may choose | 
|  | more than one without conflict.  If you don't need UML networking, | 
|  | say N. | 
|  |  | 
|  | config UML_NET_TUNTAP | 
|  | bool "TUN/TAP transport" | 
|  | depends on UML_NET | 
|  | help | 
|  | The UML TUN/TAP network transport allows a UML instance to exchange | 
|  | packets with the host over a TUN/TAP device.  This option will only | 
|  | work with a 2.4 host, unless you've applied the TUN/TAP patch to | 
|  | your 2.2 host kernel. | 
|  |  | 
|  | To use this transport, your host kernel must have support for TUN/TAP | 
|  | devices, either built-in or as a module. | 
|  |  | 
|  | config UML_NET_SLIP | 
|  | bool "SLIP transport" | 
|  | depends on UML_NET | 
|  | help | 
|  | The slip User-Mode Linux network transport allows a running UML to | 
|  | network with its host over a point-to-point link.  Unlike Ethertap, | 
|  | which can carry any Ethernet frame (and hence even non-IP packets), | 
|  | the slip transport can only carry IP packets. | 
|  |  | 
|  | To use this, your host must support slip devices. | 
|  |  | 
|  | For more information, see | 
|  | <http://user-mode-linux.sourceforge.net/old/networking.html>. | 
|  | has examples of the UML command line to use to enable slip | 
|  | networking, and details of a few quirks with it. | 
|  |  | 
|  | The Ethertap Transport is preferred over slip because of its | 
|  | limitations.  If you prefer slip, however, say Y here.  Otherwise | 
|  | choose the Multicast transport (to network multiple UMLs on | 
|  | multiple hosts), Ethertap (to network with the host and the | 
|  | outside world), and/or the Daemon transport (to network multiple | 
|  | UMLs on a single host).  You may choose more than one without | 
|  | conflict.  If you don't need UML networking, say N. | 
|  |  | 
|  | config UML_NET_DAEMON | 
|  | bool "Daemon transport" | 
|  | depends on UML_NET | 
|  | help | 
|  | This User-Mode Linux network transport allows one or more running | 
|  | UMLs on a single host to communicate with each other, but not to | 
|  | the host. | 
|  |  | 
|  | To use this form of networking, you'll need to run the UML | 
|  | networking daemon on the host. | 
|  |  | 
|  | For more information, see | 
|  | <http://user-mode-linux.sourceforge.net/old/networking.html>  That site | 
|  | has examples of the UML command line to use to enable Daemon | 
|  | networking. | 
|  |  | 
|  | If you'd like to set up a network with other UMLs on a single host, | 
|  | say Y.  If you need a network between UMLs on multiple physical | 
|  | hosts, choose the Multicast Transport.  To set up a network with | 
|  | the host and/or other IP machines, say Y to the Ethertap or Slip | 
|  | transports.  You'll need at least one of them, but may choose | 
|  | more than one without conflict.  If you don't need UML networking, | 
|  | say N. | 
|  |  | 
|  | config UML_NET_VDE | 
|  | bool "VDE transport" | 
|  | depends on UML_NET | 
|  | help | 
|  | This User-Mode Linux network transport allows one or more running | 
|  | UMLs on a single host to communicate with each other and also | 
|  | with the rest of the world using Virtual Distributed Ethernet, | 
|  | an improved fork of uml_switch. | 
|  |  | 
|  | You must have libvdeplug installed in order to build the vde | 
|  | transport into UML. | 
|  |  | 
|  | To use this form of networking, you will need to run vde_switch | 
|  | on the host. | 
|  |  | 
|  | For more information, see <http://wiki.virtualsquare.org/> | 
|  | That site has a good overview of what VDE is and also examples | 
|  | of the UML command line to use to enable VDE networking. | 
|  |  | 
|  | If you need UML networking with VDE, | 
|  | say Y. | 
|  |  | 
|  | config UML_NET_MCAST | 
|  | bool "Multicast transport" | 
|  | depends on UML_NET | 
|  | help | 
|  | This Multicast User-Mode Linux network transport allows multiple | 
|  | UMLs (even ones running on different host machines!) to talk to | 
|  | each other over a virtual ethernet network.  However, it requires | 
|  | at least one UML with one of the other transports to act as a | 
|  | bridge if any of them need to be able to talk to their hosts or any | 
|  | other IP machines. | 
|  |  | 
|  | To use this, your host kernel(s) must support IP Multicasting. | 
|  |  | 
|  | For more information, see | 
|  | <http://user-mode-linux.sourceforge.net/old/networking.html>  That site | 
|  | has examples of the UML command line to use to enable Multicast | 
|  | networking, and notes about the security of this approach. | 
|  |  | 
|  | If you need UMLs on multiple physical hosts to communicate as if | 
|  | they shared an Ethernet network, say Y.  If you need to communicate | 
|  | with other IP machines, make sure you select one of the other | 
|  | transports (possibly in addition to Multicast; they're not | 
|  | exclusive).  If you don't need to network UMLs say N to each of | 
|  | the transports. | 
|  |  | 
|  | config UML_NET_PCAP | 
|  | bool "pcap transport" | 
|  | depends on UML_NET | 
|  | help | 
|  | The pcap transport makes a pcap packet stream on the host look | 
|  | like an ethernet device inside UML.  This is useful for making | 
|  | UML act as a network monitor for the host.  You must have libcap | 
|  | installed in order to build the pcap transport into UML. | 
|  |  | 
|  | For more information, see | 
|  | <http://user-mode-linux.sourceforge.net/old/networking.html>  That site | 
|  | has examples of the UML command line to use to enable this option. | 
|  |  | 
|  | If you intend to use UML as a network monitor for the host, say | 
|  | Y here.  Otherwise, say N. | 
|  |  | 
|  | config UML_NET_SLIRP | 
|  | bool "SLiRP transport" | 
|  | depends on UML_NET | 
|  | help | 
|  | The SLiRP User-Mode Linux network transport allows a running UML | 
|  | to network by invoking a program that can handle SLIP encapsulated | 
|  | packets.  This is commonly (but not limited to) the application | 
|  | known as SLiRP, a program that can re-socket IP packets back onto | 
|  | the host on which it is run.  Only IP packets are supported, | 
|  | unlike other network transports that can handle all Ethernet | 
|  | frames.  In general, slirp allows the UML the same IP connectivity | 
|  | to the outside world that the host user is permitted, and unlike | 
|  | other transports, SLiRP works without the need of root level | 
|  | privleges, setuid binaries, or SLIP devices on the host.  This | 
|  | also means not every type of connection is possible, but most | 
|  | situations can be accommodated with carefully crafted slirp | 
|  | commands that can be passed along as part of the network device's | 
|  | setup string.  The effect of this transport on the UML is similar | 
|  | that of a host behind a firewall that masquerades all network | 
|  | connections passing through it (but is less secure). | 
|  |  | 
|  | To use this you should first have slirp compiled somewhere | 
|  | accessible on the host, and have read its documentation.  If you | 
|  | don't need UML networking, say N. | 
|  |  | 
|  | Startup example: "eth0=slirp,FE:FD:01:02:03:04,/usr/local/bin/slirp" | 
|  |  | 
|  | endmenu | 
|  |  |