[Qemu-devel] make qemu use tap0 instead of tun0

[Qemu-devel] make qemu use tap0 instead of tun0

[Jim C. Brown]

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

When in tuntap mode, qemu creates a tap device with names like tun0, tun1,
etc. which seems to confuse some users (the smart ones who ask why qemu uses
IP frames instead of ethernet frames ... or something along those lines).
Theses should be named tap0, tap1, etc. This patch fixes qemu.

I don't think this would break anything (correct qemu-ifup scripts shouldn't
care about the name of the tuntap device that qemu uses).

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

[-- Attachment #2: vl.c.patch --]
[-- Type: text/plain, Size: 442 bytes --]

--- vl.c.1	Wed Jul  6 19:03:45 2005
+++ vl.c	Wed Jul  6 19:04:23 2005
@@ -1629,7 +1629,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, "tap%d");
     ret = ioctl(fd, TUNSETIFF, (void *) &ifr);
     if (ret != 0) {
         fprintf(stderr, "warning: could not configure /dev/net/tun: no virtual network emulation\n");

Re: [Qemu-devel] make qemu use tap0 instead of tun0

[Herbert Poetzl]

On Wed, Jul 06, 2005 at 07:08:42PM -0400, Jim C. Brown wrote:
> When in tuntap mode, qemu creates a tap device with names like tun0, tun1,
> etc. which seems to confuse some users (the smart ones who ask why qemu uses
> IP frames instead of ethernet frames ... or something along those lines).
> Theses should be named tap0, tap1, etc. This patch fixes qemu.
> 
> I don't think this would break anything (correct qemu-ifup scripts shouldn't
> care about the name of the tuntap device that qemu uses).
> 
> -- 
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.

> --- vl.c.1	Wed Jul  6 19:03:45 2005
> +++ vl.c	Wed Jul  6 19:04:23 2005
> @@ -1629,7 +1629,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, "tap%d");
>      ret = ioctl(fd, TUNSETIFF, (void *) &ifr);
>      if (ret != 0) {
>          fprintf(stderr, "warning: could not configure /dev/net/tun: no virtual network emulation\n");

1.1 What is the TUN ?
 The TUN is Virtual Point-to-Point network device.
 TUN driver was designed as low level kernel support for
 IP tunneling. It provides to userland application
 two interfaces:
   - /dev/tunX - character device;
   - tunX - virtual Point-to-Point interface.

 Userland application can write IP frame to /dev/tunX
 and kernel will receive this frame from tunX interface.
 In the same time every frame that kernel writes to tunX
 interface can be read by userland application from /dev/tunX
 device.

1.2 What is the TAP ?
 The TAP is a Virtual Ethernet network device.
 TAP driver was designed as low level kernel support for
 Ethernet tunneling. It provides to userland application
 two interfaces:
   - /dev/tapX - character device;
   - tapX - virtual Ethernet interface.

 Userland application can write Ethernet frame to /dev/tapX
 and kernel will receive this frame from tapX interface.
 In the same time every frame that kernel writes to tapX
 interface can be read by userland application from /dev/tapX
 device.

(from http://vtun.sourceforge.net/tun/faq.html)

best,
Herbert

> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] make qemu use tap0 instead of tun0

[Jim C. Brown]

On Thu, Jul 07, 2005 at 03:55:30AM +0200, Herbert Poetzl wrote:
> 1.1 What is the TUN ?
>  The TUN is Virtual Point-to-Point network device.
>  TUN driver was designed as low level kernel support for
>  IP tunneling. It provides to userland application
>  two interfaces:
>    - /dev/tunX - character device;
>    - tunX - virtual Point-to-Point interface.
> 
>  Userland application can write IP frame to /dev/tunX
>  and kernel will receive this frame from tunX interface.
>  In the same time every frame that kernel writes to tunX
>  interface can be read by userland application from /dev/tunX
>  device.
> 
> 1.2 What is the TAP ?
>  The TAP is a Virtual Ethernet network device.
>  TAP driver was designed as low level kernel support for
>  Ethernet tunneling. It provides to userland application
>  two interfaces:
>    - /dev/tapX - character device;
>    - tapX - virtual Ethernet interface.
> 
>  Userland application can write Ethernet frame to /dev/tapX
>  and kernel will receive this frame from tapX interface.
>  In the same time every frame that kernel writes to tapX
>  interface can be read by userland application from /dev/tapX
>  device.
> 
> (from http://vtun.sourceforge.net/tun/faq.html)
> 
> best,
> Herbert
> 

I know this. Actually that page seems out of date, as Linux's tuntap now sends
all accesses to /dev/net/tun regardless of the type of device (tun or tap).

qemu have never used tun devices, it only uses tap devices. In other words,
qemu has never read/write IP frames, it only deals with ethernet frames. This is
why having qemu use tun0 as the device name is misleading - it makes developers
believe that qemu is using a tun device (IP frames) even though it is really
using a tap device (ethernet frames).

The current NE2000 emulation (or any hardware nic emulation for that matter)
would not work if qemu used an actual tun device.

Re: [Qemu-devel] make qemu use tap0 instead of tun0

[Jim C. Brown]

On Wed, Jul 06, 2005 at 10:05:51PM -0400, Jim C. Brown wrote:
> I know this. Actually that page seems out of date, as Linux's tuntap now sends
> all accesses to /dev/net/tun regardless of the type of device (tun or tap).
> 

I should also add that on Linux, you can set the device name to what you want -
the requirement for tapX for tap devices and tunX for tun devices is not
enforced.

Note that for BSD, the function tun_open() in vl.c does open /dev/tap.

> The current NE2000 emulation (or any hardware nic emulation for that matter)
> would not work if qemu used an actual tun device.
> 

Ok this is not 100% true either. It wouldn't be too difficult to add a layer on
top of the nic hw emulation that did ethernet frame to ip frame and vice versa
before passing the frames to a tun device. (The user mode networking code
already does ethernet frame conversion.) So it wouldn't be that difficult to
get to work, and you wouldn't lose too much either (only IP-based protocols
such as TCP or UDP would work, but I've never heard of anyone trying to use
IPX or even IPv6 with qemu so that probably is not an issue).

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] make qemu use tap0 instead of tun0

[Henrik Nordstrom]

On Wed, 6 Jul 2005, Jim C. Brown wrote:

> Ok this is not 100% true either. It wouldn't be too difficult to add a layer on
> top of the nic hw emulation that did ethernet frame to ip frame and vice versa
> before passing the frames to a tun device. (The user mode networking code
> already does ethernet frame conversion.) So it wouldn't be that difficult to
> get to work, and you wouldn't lose too much either (only IP-based protocols
> such as TCP or UDP would work, but I've never heard of anyone trying to use
> IPX or even IPv6 with qemu so that probably is not an issue).

Not entirely sure how you would map this.. tun is a point-to-point device. 
There is no broadcasts, no ARP, just plain unicast protocol packets 
(usually IP, but may be any protocol supported by the host).

Regards
Henrik

Re: [Qemu-devel] make qemu use tap0 instead of tun0

[Henrik Nordstrom]

On Wed, 6 Jul 2005, Jim C. Brown wrote:

> When in tuntap mode, qemu creates a tap device with names like tun0, tun1,
> etc. which seems to confuse some users (the smart ones who ask why qemu uses
> IP frames instead of ethernet frames ... or something along those lines).
> Theses should be named tap0, tap1, etc. This patch fixes qemu.

My understanding was is that tunX is the tun/tap driver (/dev/net/tun), 
while tapX is the older ethertap driver (/dev/tapX), but looking closely 
at the tun/tap driver you seem to be correct. As I almost always specify 
explicit device names (i.e. qemuX for qemu connections) I never really 
cared what the defaults were.

A simpler patch would be to not specify a device name template at all. 
This lets the tun/tap driver select whatever it feels suitable for the 
type of device created, defaulting to tap%d for TUN_TAP_DEV devices.

Regards
Henrik