From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BBMYj-0002hh-01 for qemu-devel@nongnu.org; Wed, 07 Apr 2004 19:34:17 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BBMYA-0002Sw-3y for qemu-devel@nongnu.org; Wed, 07 Apr 2004 19:34:13 -0400 Received: from [216.254.0.201] (helo=mail1.speakeasy.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1BBMY9-0002RO-3T for qemu-devel@nongnu.org; Wed, 07 Apr 2004 19:33:41 -0400 Date: Wed, 07 Apr 2004 18:29:26 -0500 (CDT) Message-Id: <20040407.182926.-1300526525.ayerkes@speakeasy.net> Subject: Re: [Qemu-devel] Win32 usermode only network possible? From: art yerkes In-Reply-To: <1081375468.14275.33.camel@aragorn> References: <000701c41cbf$49b386d0$0401a8c0@putte2k> <4074604D.6030201@bellard.org> <1081375468.14275.33.camel@aragorn> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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: jhoger@pobox.com, qemu-devel@nongnu.org, jhoger@speakeasy.net From: "John R. Hogerhuis" Subject: Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs] Date: Wed, 07 Apr 2004 15:04:28 -0700 Message-ID: <1081375468.14275.33.camel@aragorn> jhoger> A SOCKS proxy would allow two way communication since it allows creation jhoger> of listening sockets. But it requires configuration of the clients so jhoger> it's not zero-install. Its other advantage is that it would not require jhoger> priviledged access to the host. Most important networks apps are jhoger> socksified and the setup is very easy (tell the app to use a certain jhoger> socks server IP). Although I'm new to this discussion, I'd like to share a few thoughts I and another qemu user had earlier about networking in win32. Using SOCKS would still require each guest OS to provide some special mechanism for proxying SOCKS connections to the host OS. Since that part would be qemu specific, it's unlikely to my mind that such modifications would be well received by the guest OS developers. A userland server is desirable, however, and so SOCKS is part of the model for what follow. A while ago, I noticed a patch for bochs to put ethernet packets on normal TCP connections, along with a little virtual hub to connect the bochses together here: http://cbothamy.free.fr/projects/bochs/patch.vhub Something quite similar, but a bit less fragile is the first part of what I'd propose for qemu. It's simple and flexible. Since any type of program can handle the bochs connections, making a hub is only the most trivial thing that might be done, although that in itself is quite useful. The second thing one would do is to write a smarter hub that did a few things: - Listen for connections from qemus, and hear and relay their ethernet traffic. - Listen on some user-configured ports to relay services provided by the guest to the outside, similar to what a firewall with NAT does when redirecting incoming traffic. TCP SYN would be faked whenever a connection was ready to accept. - The proxying program must eventually handle TCP, UDP and ICMP proxying. TCP will be the only difficult part, as the hub must compose fake ethernet traffic to send to the qemus, providing a sort of super SOCKS proxy. The very nice thing about such as scheme is that it would allow the same hubbing program to work with bochs as well as qemu, as well as allowing more exotic proxy types to be developed independently from qemu. Such a scheme would also be trivial to interface to the likes of vtun and OpenVPN (which can run on windows).