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 f
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, t
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 w
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 - characte
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).
> The
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 t
