From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LncJ1-0002E2-Am for qemu-devel@nongnu.org; Sat, 28 Mar 2009 13:26:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LncIv-00029L-Tk for qemu-devel@nongnu.org; Sat, 28 Mar 2009 13:26:50 -0400 Received: from [199.232.76.173] (port=56914 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LncIv-00029I-QR for qemu-devel@nongnu.org; Sat, 28 Mar 2009 13:26:45 -0400 Received: from mail-qy0-f111.google.com ([209.85.221.111]:60358) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LncIv-0005mm-Eb for qemu-devel@nongnu.org; Sat, 28 Mar 2009 13:26:45 -0400 Received: by qyk9 with SMTP id 9so2651037qyk.4 for ; Sat, 28 Mar 2009 10:26:45 -0700 (PDT) Message-ID: <49CE5DD1.1010302@codemonkey.ws> Date: Sat, 28 Mar 2009 12:26:41 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Add pcap-based host network bridge References: <49C0BFCD.1040304@siemens.com> <49C6F2AA.40408@codemonkey.ws> <49C91829.6000606@siemens.com> In-Reply-To: <49C91829.6000606@siemens.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Jan Kiszka wrote: > To my understanding too. We will try to look closer at this, maybe there > are smarter alternatives at least on some platforms (PF_PACKET under > Linux...?). > > Klaus explained to me that there is some switch in winpcap to support > this, but it caused troubles due to weird packet loops. I don't have a > Windows platform to test, but I will see if we can clarify this in some > other way. > > >> That's a blocker IMHO because it will invariably lead to many folks >> asking why ping to the host doesn't work (just like slirp). Since it >> still requires root privileges, I don't think it improves a lot on tap. >> >> > > Well, in case we do not find a workaround for host<->guest > communication, would the patch remain unacceptable even with proper, > prominent documentation of this shortcoming? > What's the use-case you're trying to address? Who do you expect to use this functionality? Setting up bridging isn't really that bad on Linux. Is this primarily targeted at Windows? libpcap requires a kernel driver on Windows so I don't know that I believe it's a great general solution for Windows either. Regards, Anthony Liguori > Jan > >