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 1BBJMe-00038y-Ok for qemu-devel@nongnu.org; Wed, 07 Apr 2004 16:09:36 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BBJM5-0002wd-VJ for qemu-devel@nongnu.org; Wed, 07 Apr 2004 16:09:33 -0400 Received: from [193.252.22.25] (helo=mwinf0604.wanadoo.fr) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BBJM5-0002w8-Bz for qemu-devel@nongnu.org; Wed, 07 Apr 2004 16:09:01 -0400 Received: from bellard.org (ATuileries-112-1-4-213.w81-53.abo.wanadoo.fr [81.53.133.213]) by mwinf0604.wanadoo.fr (SMTP Server) with ESMTP id 24F182800155 for ; Wed, 7 Apr 2004 22:08:59 +0200 (CEST) Message-ID: <4074604D.6030201@bellard.org> Date: Wed, 07 Apr 2004 22:10:53 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs] References: <000701c41cbf$49b386d0$0401a8c0@putte2k> In-Reply-To: <000701c41cbf$49b386d0$0401a8c0@putte2k> Content-Type: text/plain; charset=us-ascii; 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 Hi, I like very much the idea of enabling network use without any priviledge rights for Linux and win32. I have looked at the SLiRP code and it seems easy to do (at least for Linux, for win32 I have not looked how to do that with the SDL event loop). Expect this feature to come in the next few days :-) The idea is the following : the raw ethernet packet coming from the virtual NE2000 card will be converted to high level socket operations (such as connect TCP connection, socket read/write). It won't work in every case (in particular no incoming TCP connection will be supported), but will allow at least to browse with the simulated OS. The limitations will be close to what you have with a firewall configuration. Fabrice. Mike Nordell wrote: > 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 > > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://mail.nongnu.org/mailman/listinfo/qemu-devel >