Re: [Qemu-devel] tun/tap networking

[Jim C. Brown]

On Fri, Sep 30, 2005 at 03:13:21PM -0700, Don Kitchen wrote:
> I've used that one "pricey" product at work, but it always seemed a bit
> expensive for home users. But I only knew about some of the other emulators,
> the ones that are so slow you wonder why didn't they warn you not to
> bother downloading the thing to start with. But qemu has definately made
> it past usability barrier.
> 

Because qemu is not an emulator per se, it is properly called a dynamic
translator.

(It's a distinction that many will quarrel over for a long time. ;)

> I have some questions about the networking that I hope someone can answer.
> Qemu is able to use tun & tap devices. I've taken the tundev.c program,
> which opens a tun device and passes the fd to qemu, and compared it to
> the tapdev.c program (which qemu is also able to use) and there's very
> little difference to how it's opened. According to the little tun/tap
> documentation I understand, the tap descriptor should be providing
> ethernet frames instead of the IP packets [ethernet payloads] that tun
> should be providing. But qemu does not seem to differentiate between the
> two types of file descriptors passed by tundev and tapdev respectively,
> so I am a little confused how qemu can work with both types of fd's.
> 

I am confused as well. Are you sure that tundev.c creates a tun device? Or
is it creating a tap device that is named tun0?

Typically, tapX (tap0, tap1, etc) names are reserved for tap devices (ethernet
frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP frames).

qemu breaks those rules and calls the tap device that it creates tun0. This is
done for reasons that Fabrice has not made clear. (I assume there is a reason
for it because he has refused to apply any of the patches that fix this.)

qemu has no support for true tun devices. It only deals with ethernet frames,
so it only works with tap devices. You can tell because a tap device is
opened when you add a special flag, IFF_TAP, to the ifr_flags of the TUNSETIFF
ioctl call.

> I'm interested in the handling of ethernet frames because I haven't been
> able to get the bridge to pass packets between added interfaces (yes,
> they're all up and promisc) and I'm not too thrilled with networking being
> bridged anyway,

Do you mean the kernel bridge, br0? Or are you talking about some sort of
user space bridge, like bridged (which uses a series of packet sockets to
bridge between multiple ethernet (ethX) devices) ?

> and it seems to me that if an fd were hooked up to a
> BPF capturing everything from the real ethernet device in promiscuous
> mode, and pushing out any raw frames it receives, that I could bypass
> the bridge and make it as if the emulator's virtual ethernet device is
> a real one. Or is there some reason this won't work? (after all, other
> products don't have this, there must be a reason right?)

Ah, you're talking about using a packet socket, right?

That works fine for the most part. There is one thing that you have missed
though: guest->host communication doesn't work when you do that.

When you push out a raw frame, it leaves the real ethernet device before the
host sees it. So guest->host doesn't work. You need to find another way to
send packets from the guest to the host. Most host OSes will not let you
do this at all. (Windows seems to be the exception, winpcap's pcap_sendpacket()
appears to work fine for that job.)

VMware gets around this by using its kernel module: when the guest sends 
something
to the host, VMware passes the packet to its kernel module, which injects it
into the incoming packet stream. Without your own kernel module though, you
can't do this.

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

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