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 1BBG8c-00037R-1u for qemu-devel@nongnu.org; Wed, 07 Apr 2004 12:42:54 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BBG81-0002rS-0j for qemu-devel@nongnu.org; Wed, 07 Apr 2004 12:42:48 -0400 Received: from [81.228.9.108] (helo=av2-2-sn3.vrr.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BBG80-0002qe-Eg for qemu-devel@nongnu.org; Wed, 07 Apr 2004 12:42:16 -0400 Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av2-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 2244137E4C for ; Wed, 7 Apr 2004 18:42:14 +0200 (CEST) Received: from putte2k (h151n2fls306o994.telia.com [81.225.243.151]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id DFA293804D for ; Wed, 7 Apr 2004 18:42:13 +0200 (CEST) Message-ID: <000701c41cbf$49b386d0$0401a8c0@putte2k> From: "Mike Nordell" Date: Wed, 7 Apr 2004 18:42:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs] 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 John R. Hogerhuis wrote > On the user space issue, I guess that's not completely true when > it comes to networking? You have to be using the TUN/TAP driver. This is something I've been thinking about, and maybe, just maybe, I might have got an idea to make it work on at least later (host) NT's - the ones that can give you raw access, allow you to write your own e.g. IP headers. The most likely protocols to encounter would be IP, followed by ICMP. Should anyone want IPX, or even NetBEUI - sure, make it a plug-in architecture. What if some piece of code was given low-level protocol knowledge, to let the OS'es running in QEMU happily think they talk to a NIC (be it NE2k, or a card with some more speed and less interrupt requirements), but that the emulated card in turn was "connected" to a piece of software, let's for now call it the protocol parser (PP), that also knew IP and ICMP? I envision this piece of code as either a part of the QEMU process, or a separate process (let's not bother about the IPC - that's easy in comparison), parsing the emitted ethernet packets from the QEMU virtual NIC, and in effect acting as a NAT (and then some). Sure, it wouldn't run light lightning, but it could be a completely user-mode solution. Running this thing as a separate process would probably make it slower, but it could also enable the possibility to run the QEMU process(es) with less than Administrator privileges - while the component getting this raw access to the host NIC obviously would need them. That's the reason I mentioned the possibility of emulating anopther card than NE2k, which is probably the most inefficient of all NIC's, even if comparatively easy to implement an emulator for. As for the idea about a SOCKS (or any other kind of) proxy; I'm fairly sure that'd only work for operating systems where a QEMU-special implementation was created (either by the OS, or in QEMU itself - by trapping syscalls and so on), why it wouldn't be a viable solution for but some limited cases. OK, it could probably be done without too much effort for e.g. a specific Linux version (maybe even many), but from my POV it'd be very fragile in depending on specific versions of specific OSes. Please don't see this as a suggestion, I'm just bouncing an idea I've had for a while. /Mike