[Qemu-devel] pcap-based networking?

[Qemu-devel] pcap-based networking?

[Mike Tremoulet]

All --

Apologies if this design decision has been worked before.  I've
successfully run various *nixes on my Win2K host, and while the slirp
solution usually works, I was thinking of ways to make it more
flexible.

I haven't finished identifying parts of the source code yet (my C
skills aren't that sharp), but from what I can tell, the tun/tap
interface uses file read/write operations to work on Unix, and the
slirp module does its thing somewhere as well, and the choice is made
by compile options and command-line switches.

My question is:  Is there a reason to use (or not to use) a
libpcap/libnet solution for networking?  At a high level, I think of
it as a queue of incoming packets and a queue of outgoing packets
(from the standpoint of the guest).  Outgoing packets from the guest
would be held in a queue and written onto the network via libnet, and
incoming packets would get captured by libpcap and written to the
virtual device.

The advantages for me would be:
- I can bind this networking to the device of my explicit choosing at
runtime.  So, I could install a tap device on my host and have qemu
always use that device, or I could bind it to a second NIC on the
host.
- More importantly, this can be somewhat platform independant. 
Libpcap exists in a very similar, if not identical, API in the form of
winpcap.  I know there is an equivalent way to write packets to the
network, but I forget the name right now.

What would the potential performance impacts be?  Is this something
that I/we should pursue?  Other thoughts?

-- Mike

Re: [Qemu-devel] pcap-based networking?

[John R. Hogerhuis]

On Thu, 2004-08-26 at 09:42, Mike Tremoulet wrote:
> All --
> 
> Apologies if this design decision has been worked before.  I've
> successfully run various *nixes on my Win2K host, and while the slirp
> solution usually works, I was thinking of ways to make it more
> flexible.

Just to clarify, TUN/TAP and user mode serve different ends.

User mode is zero-configuration, and does not require administrative
rights to set it up. The slirp code code be improved in many ways, and
the strategy has inherenent limitations, but as I said it has clear
advantages.

Any alternative for the slirp solution would have to meet the
zero-config, no admin rights test.

TUN/TAP is just a packet forwarding/tunnel solution, just like what you
are describing. It is harder to set up than user mode networking, you
need admin rights, but it is faster and certainly more flexible than
user mode. It seems to me you are describing an alternative to TUN/TAP
not user mode networing.

As far as your specific suggestions for improvement over TUN/TAP, I will
let others pick that apart.

-- John.

Re: [Qemu-devel] pcap-based networking?

[Mike Tremoulet]

On Thu, 26 Aug 2004 10:15:21 -0700, John R. Hogerhuis <jhoger@pobox.com> wrote:
> Just to clarify, TUN/TAP and user mode serve different ends.
> 
> User mode is zero-configuration, and does not require administrative
> rights to set it up. The slirp code code be improved in many ways, and
> the strategy has inherenent limitations, but as I said it has clear
> advantages.
> 
> Any alternative for the slirp solution would have to meet the
> zero-config, no admin rights test.
> 
> TUN/TAP is just a packet forwarding/tunnel solution, just like what you
> are describing. It is harder to set up than user mode networking, you
> need admin rights, but it is faster and certainly more flexible than
> user mode. It seems to me you are describing an alternative to TUN/TAP
> not user mode networing.
> 

True.  That's a better way to say it - can I have a TUN/TAP
alternative that runs on Windows?  It wouldn't be zero-config, but the
config could be minimal - install a TAP adapter, enable Internet
Connection Sharing, and point QEMU at the TAP interface.

Thanks for the clarification,
-- Mike

Re: [Qemu-devel] pcap-based networking?

[John R. Hogerhuis]

On Thu, 2004-08-26 at 10:19, Mike Tremoulet wrote:

> True.  That's a better way to say it - can I have a TUN/TAP
> alternative that runs on Windows?  It wouldn't be zero-config, but the
> config could be minimal - install a TAP adapter, enable Internet
> Connection Sharing, and point QEMU at the TAP interface.

For windows, w/ admin rights, it looks like your solution is probably
the way to do it.

Probably you should make an installer too that can set up pcap on
windows along with QEMU. That would answer the difficulty of install
question effectively (although not the admin issue). Maybe you should
team up with one of the folks producing windows gui front end to QEMU...
search the archives, I think there are a few out there.

-- John

Re: [Qemu-devel] pcap-based networking?

[Mike Tremoulet]

On Thu, 26 Aug 2004 10:48:45 -0700, John R. Hogerhuis <jhoger@pobox.com> wrote:
> For windows, w/ admin rights, it looks like your solution is probably
> the way to do it.
> 
> Probably you should make an installer too that can set up pcap on
> windows along with QEMU. That would answer the difficulty of install
> question effectively (although not the admin issue). Maybe you should
> team up with one of the folks producing windows gui front end to QEMU...
> search the archives, I think there are a few out there.
> 
> -- John

So, having said all that, is there a quickstart guide to understanding
the structure/design of the current qemu code?  I'm going to have to
learn the guts of pcap programming, remember how c actually works, and
basically come up to speed on a lot of things.

-- Mike

Re: [Qemu-devel] pcap-based networking?

[John R. Hogerhuis]

On Thu, 2004-08-26 at 23:08, Mike Tremoulet wrote:

> So, having said all that, is there a quickstart guide to understanding
> the structure/design of the current qemu code?  I'm going to have to
> learn the guts of pcap programming, remember how c actually works, and
> basically come up to speed on a lot of things.
> 

No. There's lots of code. Some documentation. But 95% of the code (and
the documentation) doesn't have anything to do with networking. Just
focus on the sections that matter to you. As you come up against
problems, get your copy of K&R, ask someone on IRC, or if it's QEMU
specific ask here on the list.

The pcap stuff is just a library/API. Any API takes some time to learn,
but at least you have the source if the API documentation is
problematic.

Anyway half the reason for working with Free Software is that when I
invest time to learn something, I can actually take that knowledge with
me and apply it anywhere I go without worrying about violating someone's
trade secrets or proprietary intellectual property. At the risk of being
patronizing, my advice if you want to be a good FOSS programmer is never
be afraid of learning anything. Don't plan to think about starting to do
something... just jump in and get it done.

-- John.

Re: [Qemu-devel] pcap-based networking?

[Mike Tremoulet]

On Thu, 26 Aug 2004 23:28:31 -0700, John R. Hogerhuis <jhoger@pobox.com> wrote:
> No. There's lots of code. Some documentation. But 95% of the code (and
> the documentation) doesn't have anything to do with networking. Just
> focus on the sections that matter to you. As you come up against
> problems, get your copy of K&R, ask someone on IRC, or if it's QEMU
> specific ask here on the list.

Cool.  That's what I suspected, but I wanted to ask to be sure.

> 
> The pcap stuff is just a library/API. Any API takes some time to learn,
> but at least you have the source if the API documentation is
> problematic.
> 

I've found some decent tutorials in the past for that, so I can should be set.

> Anyway half the reason for working with Free Software is that when I
> invest time to learn something, I can actually take that knowledge with
> me and apply it anywhere I go without worrying about violating someone's
> trade secrets or proprietary intellectual property. At the risk of being
> patronizing, my advice if you want to be a good FOSS programmer is never
> be afraid of learning anything. Don't plan to think about starting to do
> something... just jump in and get it done.

Learning is the fun part.  My concern is appearing to commit to a
project that, frankly, I don't know if I'll have the time to finish. 
(And yes, this is my first contribution to FOSS.  Heck of a place to
start.)

-- Mike

Re: [Qemu-devel] pcap-based networking?

[Jim C. Brown]

On Thu, Aug 26, 2004 at 11:42:45AM -0500, Mike Tremoulet wrote:
> All --
> 
> My question is:  Is there a reason to use (or not to use) a
> libpcap/libnet solution for networking?  At a high level, I think of
> it as a queue of incoming packets and a queue of outgoing packets
> (from the standpoint of the guest).  Outgoing packets from the guest
> would be held in a queue and written onto the network via libnet, and
> incoming packets would get captured by libpcap and written to the
> virtual device.
> 
> The advantages for me would be:
> - I can bind this networking to the device of my explicit choosing at
> runtime.  So, I could install a tap device on my host and have qemu
> always use that device, or I could bind it to a second NIC on the
> host.
> - More importantly, this can be somewhat platform independant. 
> Libpcap exists in a very similar, if not identical, API in the form of
> winpcap.  I know there is an equivalent way to write packets to the
> network, but I forget the name right now.
> 
> What would the potential performance impacts be?  Is this something
> that I/we should pursue?  Other thoughts?
> 
> -- Mike

This is a good idea. We should keep the tuntap interface, but adding support
for libpcap is useful for those OSes which do not have a tuntap-like interface.

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

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