[Qemu-devel] [patch] Linux TUN/TAP driver updates

[Qemu-devel] [patch] Linux TUN/TAP driver updates

[Henrik Nordstrom]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1249 bytes --]

The attached patch updates the Linux TUN/TAP interface

   - Allow use of static/persistent TUN/TAP devices, eleminating the need 
to run anything as root when starting qemu.

   - A minor bugfix in filedescriptor based TUN/TAP devices to allow more 
than one filedescriptor (was colliding on the qemu internal device name).

   - Added the interface index as argument to the ifup script to simplify 
integration.


A small howto use persistent TUN/TAP devices:

1. Grab the tunctl tool from UML. 
<url:http://www.user-mode-linux.org/cvs/tools/tunctl/>
<url:http://www.fifi.org/cgi-bin/man2html/usr/share/man/man1/tunctl.1.gz>

this small tools allows you to create persistent TAP devices with a 
fixed name on the host. A persistent tap device stays until it is manually 
deleted with tunctl.

2. Configure the host side of the created TAP devices using your normal 
network setup tools, or the network configuration tools provided by your 
distribution vendor if preferred.

3. When starting qemu, specify the TAP device names with the new -tun-dev 
qemu command line option.

       -tun-dev name   use this already created tun device

-tun-dev can be specified multiple times if you want qemu to connect to 
more than one device.

Regards
Henrik

[-- Attachment #2: Type: TEXT/PLAIN, Size: 4116 bytes --]

Index: vl.c
===================================================================
RCS file: /cvsroot/qemu/qemu/vl.c,v
retrieving revision 1.126
diff -u -r1.126 vl.c
--- vl.c	7 Apr 2005 22:20:28 -0000	1.126
+++ vl.c	15 Apr 2005 15:45:44 -0000
@@ -1623,14 +1623,16 @@
     }
     memset(&ifr, 0, sizeof(ifr));
     ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
-    pstrcpy(ifr.ifr_name, IFNAMSIZ, "tun%d");
+    if (*ifname)
+	pstrcpy(ifr.ifr_name, IFNAMSIZ, ifname);
+    else
+	pstrcpy(ifr.ifr_name, IFNAMSIZ, "tun%d");
     ret = ioctl(fd, TUNSETIFF, (void *) &ifr);
     if (ret != 0) {
         fprintf(stderr, "warning: could not configure /dev/net/tun: no virtual network emulation\n");
         close(fd);
         return -1;
     }
-    printf("Connected to host network interface: %s\n", ifr.ifr_name);
     pstrcpy(ifname, ifname_size, ifr.ifr_name);
     fcntl(fd, F_SETFL, O_NONBLOCK);
     return fd;
@@ -1652,20 +1654,24 @@
 static int net_tun_init(NetDriverState *nd)
 {
     int pid, status;
-    char *args[3];
-    char **parg;
 
     nd->fd = tun_open(nd->ifname, sizeof(nd->ifname));
     if (nd->fd < 0)
         return -1;
 
+    printf("Network %d connected to host network interface: %s\n", nd->index, nd->ifname);
     /* try to launch network init script */
     pid = fork();
     if (pid >= 0) {
         if (pid == 0) {
+	    char ifnum[4];
+	    char *args[4];
+	    char **parg;
+	    snprintf(ifnum, sizeof(ifnum), "%d", nd->index);
             parg = args;
             *parg++ = network_script;
             *parg++ = nd->ifname;
+            *parg++ = ifnum;
             *parg++ = NULL;
             execv(network_script, args);
             exit(1);
@@ -1687,7 +1693,7 @@
     nd->fd = fd;
     nd->send_packet = tun_send_packet;
     nd->add_read_packet = tun_add_read_packet;
-    pstrcpy(nd->ifname, sizeof(nd->ifname), "tunfd");
+    snprintf(nd->ifname, sizeof(nd->ifname), "tunfd%d", fd);
     return 0;
 }
 
@@ -2758,6 +2764,7 @@
            "-macaddr addr   set the mac address of the first interface\n"
            "-n script       set tap/tun network init script [default=%s]\n"
            "-tun-fd fd      use this fd as already opened tap/tun interface\n"
+           "-tun-dev name   use this already created tun device\n"
 #ifdef CONFIG_SLIRP
            "-user-net       use user mode network stack [default if no tap/tun script]\n"
            "-tftp prefix    allow tftp access to files starting with prefix [-user-net]\n"
@@ -2846,6 +2853,7 @@
     QEMU_OPTION_macaddr,
     QEMU_OPTION_n,
     QEMU_OPTION_tun_fd,
+    QEMU_OPTION_tun_dev,
     QEMU_OPTION_user_net,
     QEMU_OPTION_tftp,
     QEMU_OPTION_smb,
@@ -2907,6 +2915,7 @@
     { "macaddr", HAS_ARG, QEMU_OPTION_macaddr},
     { "n", HAS_ARG, QEMU_OPTION_n },
     { "tun-fd", HAS_ARG, QEMU_OPTION_tun_fd },
+    { "tun-dev", HAS_ARG, QEMU_OPTION_tun_dev },
 #ifdef CONFIG_SLIRP
     { "user-net", 0, QEMU_OPTION_user_net },
     { "tftp", HAS_ARG, QEMU_OPTION_tftp },
@@ -3018,7 +3027,7 @@
     int cyls, heads, secs, translation;
     int start_emulation = 1;
     uint8_t macaddr[6];
-    int net_if_type, nb_tun_fds, tun_fds[MAX_NICS];
+    int net_if_type, nb_tun_fds, tun_fds[MAX_NICS], nb_tun_devices;
     int optind;
     const char *r, *optarg;
     CharDriverState *monitor_hd;
@@ -3066,6 +3075,7 @@
     parallel_device_index = 0;
     
     nb_tun_fds = 0;
+    nb_tun_devices = 0;
     net_if_type = -1;
     nb_nics = 1;
     /* default mac address of the first network interface */
@@ -3184,6 +3194,15 @@
                     }
                 }
 		break;
+	    case QEMU_OPTION_tun_dev:
+                {
+                    net_if_type = NET_IF_TUN;
+                    if (nb_tun_devices < MAX_NICS) {
+			pstrcpy(nd_table[nb_tun_devices].ifname, sizeof(nd_table[nb_tun_devices].ifname), optarg);
+			nb_tun_devices++;
+		    }
+                }
+		break;
             case QEMU_OPTION_hdc:
                 hd_filename[2] = optarg;
                 has_cdrom = 0;

[Qemu-devel] Regarding Linux TUN/TAP

[Hetz Ben Hamo]

Hi Henrik, all..

Henrik, I think your patch is great and surely can help when using TUN/TAP..

However, I would like to point an issue (and I'm not criticizing
anyone here, I'm just asking for people thoughts, solutions)..

The SLiRP solution for QEMU is great if a user want to connect to the
net and browse, do some updates, etc, but it's not a good solution if
someone want to stuff like:

* Connect to host OS
* Connect to other machines in the LAN
* Use services from host OS

For the things in the list above to make them work, the solution is to
use TUN/TAP and/or VDE. These are great solutions  - but setting them
up is quite a challange for people who are nor familiar (or doesn't
have a big knowledge) with Linux.

What do people think could be a solution for end users? comments?

Thanks,
Hetz

On 4/15/05, Henrik Nordstrom <hno@marasystems.com> wrote:
> The attached patch updates the Linux TUN/TAP interface
>

Re: [Qemu-devel] Regarding Linux TUN/TAP

[Laurent Amon]

Hi Hetz,

On 15 avr. 05, at 22:07, Hetz Ben Hamo wrote:
> The SLiRP solution for QEMU is great if a user want to connect to the
> net and browse, do some updates, etc, but it's not a good solution if
> someone want to stuff like:
>
> * Connect to host OS
> * Connect to other machines in the LAN
> * Use services from host OS
>
> For the things in the list above to make them work, the solution is to
> use TUN/TAP and/or VDE. These are great solutions  - but setting them
> up is quite a challange for people who are nor familiar (or doesn't
> have a big knowledge) with Linux.
>
I don't really follow you. I believe Slirp is OK when you want to 
connect from the guest to the host or the net at large. Didn't you mean 
"guest" instead of "host" in the sentences above?

Another solution would be to run a PPP server on the host and connect 
through PPP (using user-net) from the guest to the host. In this case, 
provided the host routes the connection, you should have your virtual 
machine fully on the net.

Lga.

Re: [Qemu-devel] Regarding Linux TUN/TAP

[Paul Brook]

> Another solution would be to run a PPP server on the host and connect
> through PPP (using user-net) from the guest to the host. In this case,
> provided the host routes the connection, you should have your virtual
> machine fully on the net.

This is no better than just using tun/tap. In fact it takes significantly more 
work to setup, and is probably slower.

Paul

Re: [Qemu-devel] [patch] Linux TUN/TAP driver updates

[Jean-Christian de Rivaz]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

Hi,

This is a good idea. I haved posted a similar patch to this mailing list 
the 13 feb 2005 but I have see no reaction at all at this time. Maybe 
you can find something usefull in the attached patch to improve the 
support of static TUN/TAP. The patch is outdated now, but I can update 
it to the current CVS if there is any interrest. Just tell me.

Static TUN is good in the situation where you have a superuser that 
manage the interfaces. It set them and assign them to each users. it can 
also setup a DHCP server to distribute IP addresses. Users just lunch 
quemu with there static TUN in the option and magicaly get a working 
network without any need to sudo, setuid or whatever that can have any 
security risk.

You can also imagine a virtual machine manager application that setup 
the network interfaces and lunch the qemu instances. This is the 
direction I like the most.

Have a good day,
--
Henrik Nordstrom a écrit :
> The attached patch updates the Linux TUN/TAP interface
> 
>   - Allow use of static/persistent TUN/TAP devices, eleminating the need 
> to run anything as root when starting qemu.
> 
>   - A minor bugfix in filedescriptor based TUN/TAP devices to allow more 
> than one filedescriptor (was colliding on the qemu internal device name).
> 
>   - Added the interface index as argument to the ifup script to simplify 
> integration.
> 
> 
> A small howto use persistent TUN/TAP devices:
> 
> 1. Grab the tunctl tool from UML. 
> <url:http://www.user-mode-linux.org/cvs/tools/tunctl/>
> <url:http://www.fifi.org/cgi-bin/man2html/usr/share/man/man1/tunctl.1.gz>
> 
> this small tools allows you to create persistent TAP devices with a 
> fixed name on the host. A persistent tap device stays until it is 
> manually deleted with tunctl.
> 
> 2. Configure the host side of the created TAP devices using your normal 
> network setup tools, or the network configuration tools provided by your 
> distribution vendor if preferred.
> 
> 3. When starting qemu, specify the TAP device names with the new 
> -tun-dev qemu command line option.
> 
>       -tun-dev name   use this already created tun device
> 
> -tun-dev can be specified multiple times if you want qemu to connect to 
> more than one device.
> 
> Regards
> Henrik


-- 
Jean-Christian de Rivaz

[-- Attachment #2: tun.patch --]
[-- Type: text/x-patch, Size: 5683 bytes --]

Index: qemu-doc.texi
===================================================================
RCS file: /cvsroot/qemu/qemu/qemu-doc.texi,v
retrieving revision 1.55
diff -u -r1.55 qemu-doc.texi
--- qemu-doc.texi	10 Feb 2005 21:46:47 -0000	1.55
+++ qemu-doc.texi	13 Feb 2005 01:59:04 -0000
@@ -212,6 +212,22 @@
 aa:bb:cc:dd:ee:ff in hexa). The mac address is incremented for each
 new network interface.
 
+@item -tun devname
+Try to use @var{devname} while opening a tap/tun host network interface and use
+it. If it work, the network init script is not executed for this
+interface. If it don't work, the interface will use the name assigned
+by the operating system and the network init script is executed.
+
+This option permit the use of preconfigured interface. For example, as
+root you can assign a tun interface to a user and configure it like this:
+@example
+tunctl -u bob -t tun2
+ifconfig tun2 192.168.2.1
+@end example
+Then bob can use this interface with the option "-tun tun2". Note that
+option permit the use of a DHCP server on the host to configure the
+guest interface.
+
 @item -tun-fd fd
 Assumes @var{fd} talks to a tap/tun host network interface and use
 it. Read @url{http://bellard.org/qemu/tetrinet.html} to have an
Index: vl.c
===================================================================
RCS file: /cvsroot/qemu/qemu/vl.c,v
retrieving revision 1.120
diff -u -r1.120 vl.c
--- vl.c	10 Feb 2005 22:00:06 -0000	1.120
+++ vl.c	13 Feb 2005 01:59:05 -0000
@@ -1600,7 +1600,7 @@
     }
     memset(&ifr, 0, sizeof(ifr));
     ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
-    pstrcpy(ifr.ifr_name, IFNAMSIZ, "tun%d");
+    pstrcpy(ifr.ifr_name, IFNAMSIZ, (ifname && *ifname) ? ifname : "tun%d");
     ret = ioctl(fd, TUNSETIFF, (void *) &ifr);
     if (ret != 0) {
         fprintf(stderr, "warning: could not configure /dev/net/tun: no virtual network emulation\n");
@@ -1626,7 +1626,7 @@
     qemu_add_fd_read_handler(nd->fd, fd_can_read, fd_read, opaque);
 }
 
-static int net_tun_init(NetDriverState *nd)
+static int net_tun_init(NetDriverState *nd, int script)
 {
     int pid, status;
     char *args[3];
@@ -1637,7 +1637,7 @@
         return -1;
 
     /* try to launch network init script */
-    pid = fork();
+    pid = script ? fork() : -1;
     if (pid >= 0) {
         if (pid == 0) {
             parg = args;
@@ -2731,6 +2731,7 @@
            "-nics n         simulate 'n' network cards [default=1]\n"
            "-macaddr addr   set the mac address of the first interface\n"
            "-n script       set tap/tun network init script [default=%s]\n"
+           "-tun devname    try to use devname while opening tap/tun interface\n"
            "-tun-fd fd      use this fd as already opened tap/tun interface\n"
 #ifdef CONFIG_SLIRP
            "-user-net       use user mode network stack [default if no tap/tun script]\n"
@@ -2819,6 +2820,7 @@
     QEMU_OPTION_nics,
     QEMU_OPTION_macaddr,
     QEMU_OPTION_n,
+    QEMU_OPTION_tun,
     QEMU_OPTION_tun_fd,
     QEMU_OPTION_user_net,
     QEMU_OPTION_tftp,
@@ -2880,6 +2882,7 @@
     { "nics", HAS_ARG, QEMU_OPTION_nics},
     { "macaddr", HAS_ARG, QEMU_OPTION_macaddr},
     { "n", HAS_ARG, QEMU_OPTION_n },
+    { "tun", HAS_ARG, QEMU_OPTION_tun },
     { "tun-fd", HAS_ARG, QEMU_OPTION_tun_fd },
 #ifdef CONFIG_SLIRP
     { "user-net", 0, QEMU_OPTION_user_net },
@@ -2990,7 +2993,7 @@
     int cyls, heads, secs, translation;
     int start_emulation = 1;
     uint8_t macaddr[6];
-    int net_if_type, nb_tun_fds, tun_fds[MAX_NICS];
+    int net_if_type, nb_tun, nb_tun_fds, cnt_tun_fds, tun_fds[MAX_NICS];
     int optind;
     const char *r, *optarg;
     CharDriverState *monitor_hd;
@@ -3037,7 +3040,12 @@
         parallel_devices[i][0] = '\0';
     parallel_device_index = 0;
     
+    for(i = 0; i < MAX_NICS; i++) {
+	nd_table[i].ifname[0] = '\0';
+    }
+    nb_tun = 0;
     nb_tun_fds = 0;
+    cnt_tun_fds = 0;
     net_if_type = -1;
     nb_nics = 1;
     /* default mac address of the first network interface */
@@ -3141,18 +3149,25 @@
             case QEMU_OPTION_append:
                 kernel_cmdline = optarg;
                 break;
+	    case QEMU_OPTION_tun:
+		net_if_type = NET_IF_TUN;
+		if (nb_tun+nb_tun_fds < MAX_NICS) {
+		    pstrcpy(nd_table[nb_tun++].ifname, IFNAMSIZ, optarg);
+		}
+		break;
 	    case QEMU_OPTION_tun_fd:
                 {
                     const char *p;
                     int fd;
                     net_if_type = NET_IF_TUN;
-                    if (nb_tun_fds < MAX_NICS) {
+                    if (nb_tun+nb_tun_fds < MAX_NICS) {
                         fd = strtol(optarg, (char **)&p, 0);
                         if (*p != '\0') {
                             fprintf(stderr, "qemu: invalid fd for network interface %d\n", nb_tun_fds);
                             exit(1);
                         }
                         tun_fds[nb_tun_fds++] = fd;
+			nb_tun++;
                     }
                 }
 		break;
@@ -3426,12 +3441,20 @@
 #endif
 #if !defined(_WIN32)
         case NET_IF_TUN:
-            if (i < nb_tun_fds) {
-                net_fd_init(nd, tun_fds[i]);
-            } else {
-                if (net_tun_init(nd) < 0)
-                    net_dummy_init(nd);
-            }
+	    if (nd->ifname && *(nd->ifname)) {
+		if (net_tun_init(nd, 0) < 0) {
+		    nd->ifname[0] = '\0';
+		    if (net_tun_init(nd, 1) < 0)
+		      net_dummy_init(nd);
+		}
+	    } else {
+		if (cnt_tun_fds < nb_tun_fds) {
+		    net_fd_init(nd, tun_fds[cnt_tun_fds++]);
+		} else {
+		    if (net_tun_init(nd, 1) < 0)
+		      net_dummy_init(nd);
+		}
+	    }
             break;
 #endif
         case NET_IF_DUMMY:

Re: [Qemu-devel] [patch] Linux TUN/TAP driver updates

[emuls]

Hello,

I allready use UML tool tunctl with QEMU and it works OK.

I like then I can have under control creation and use of tun0
device plus I dont need to play with SUDO (SElinux).

Rudolf
 
----- PŮVODNÍ ZPRÁVA -----
Od: "Jean-Christian de Rivaz" <jc@eclis.ch>
Komu: qemu-devel@nongnu.org
Předmět: Re: [Qemu-devel] [patch] Linux TUN/TAP driver
Datum: 16.4.2005 - 0:46:13

> Hi,
> 
> This is a good idea. I haved posted a similar patch to
> this mailing list 
> the 13 feb 2005 but I have see no reaction at all at
> this time. Maybe 
> you can find something usefull in the attached patch to
> improve the 
> support of static TUN/TAP. The patch is outdated now,
> but I can update 
> it to the current CVS if there is any interrest. Just
> tell me.
> 
> Static TUN is good in the situation where you have a
> superuser that 
> manage the interfaces. It set them and assign them to
> each users. it can 
> also setup a DHCP server to distribute IP addresses.
> Users just lunch 
> quemu with there static TUN in the option and magicaly
> get a working 
> network without any need to sudo, setuid or whatever
> that can have any 
> security risk.
> 
> You can also imagine a virtual machine manager
> application that setup 
> the network interfaces and lunch the qemu instances.
> This is the 
> direction I like the most.
> 
> Have a good day,
> --
> Henrik Nordstrom a écrit :
> > The attached patch updates the Linux TUN/TAP
> > interface
> > 
> >   - Allow use of static/persistent TUN/TAP devices,
> >   - eleminating the need 
> > to run anything as root when starting qemu.
> > 
> >   - A minor bugfix in filedescriptor based TUN/TAP
> >   - devices to allow more 
> > than one filedescriptor (was colliding on the qemu
> > internal device name).
> > 
> >   - Added the interface index as argument to the ifup
> >   - script to simplify 
> > integration.
> > 
> > 
> > A small howto use persistent TUN/TAP devices:
> > 
> > 1. Grab the tunctl tool from UML. 
> > <url:http://www.user-mode-linux.org/cvs/tools/tunctl/>
> >
<url:http://www.fifi.org/cgi-bin/man2html/usr/share/man/man1/tunctl.1.gz>
> > 
> > this small tools allows you to create persistent TAP
> > devices with a 
> > fixed name on the host. A persistent tap device stays
> > until it is 
> > manually deleted with tunctl.
> > 
> > 2. Configure the host side of the created TAP devices
> > using your normal 
> > network setup tools, or the network configuration
> > tools provided by your 
> > distribution vendor if preferred.
> > 
> > 3. When starting qemu, specify the TAP device names
> > with the new 
> > -tun-dev qemu command line option.
> > 
> >       -tun-dev name   use this already created tun
> >       -device
> > 
> > -tun-dev can be specified multiple times if you want
> > -qemu to connect to 
> > more than one device.
> > 
> > Regards
> > Henrik
> 
> 
> -- 
> Jean-Christian de Rivaz
> 


-- 
Ochrana proti přesměrování na drahé linky. Již žádné vysoké účty!
VOLNÝ internet alarm - ještě bezpečnější surfování!
Stažení i používání je ZDARMA na http://alarm.volny.cz

Re: [Qemu-devel] Regarding Linux TUN/TAP

[Henrik Nordstrom]

On Fri, 15 Apr 2005, Hetz Ben Hamo wrote:

> The SLiRP solution for QEMU is great if a user want to connect to the 
> net and browse, do some updates, etc, but it's not a good solution if 
> someone want to stuff like:
>
> * Connect to host OS
> * Connect to other machines in the LAN
> * Use services from host OS
>
> What do people think could be a solution for end users? comments?

For all of the above the user-net (SLiRP based) solution works reasonably 
fine provided you do not need to rely on fixed source port numbers. What 
it does not work well for is connectivity in the opposite direction where 
something needs to connect to the guest.

  * Connect from host OS to guest
  * Connect from LAN to guest
  * Provide services to the LAN or host.

when using user-net this requires careful planning to map the ports in a 
desired manner, and can not be done for low port numbers unless you start 
qemu as root..

Note: For Windows guests you need to set up WINS for user-net to work 
reasonably OK for accessing the LAN.


For access to the guest the solution with persistent TUN devices is 
trivial to document in a no-brainer manner for these as it very much 
resembles your normal networking configuration, and with the help of 
bridgeing can even place the quest on the local broadcast LAN as if it was 
a host of it's own. The main hinderance is that the tuncfg tool is not 
easily available on all distributions to set up the virtual NICs 
connecting to your QEMU environment(s) and without it you have to rely on 
the qemu ifup script to set things up when you start qemu with all the 
security implications it gives of allowing users to run the ifup script 
with root privs..

For more advanced setups with more than one QEMU the vde user-space 
ethernet switch is probably the way to go for user friendlyness. It is 
also possible with multiple host TUN/TAP devices and bridgeing but the 
host configuration quickly becomes somewhat complex as one TUN/TAP host 
interface is required per QEMU nic.

Regards
Henrik