[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional

From: Henrik Nordstrom
Subject: Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
Date: Mon, 13 Jun 2005 02:02:49 +0200 (CEST)

On Sat, 11 Jun 2005, Jim C. Brown wrote:

With the user-net port redirection the wrapper can automate the task,
dynamically assigning a port to the FTP server and map this on port 21 of
the router.

Ok this might be slightly useful. Still, any sane client should support using
a non-standard port, so this isn't a major issue.

It's mainly a usability issue.

By using the SLIRP port-redirection the port assignment and FTP protocol support can be automated, and all the user is to remember is that he should FTP to the router IP.

I agree. While I believe this can be worked around (given a cooperative ftpd),
having a child process for every data connection is really not worth the
trouble. It's just too ugly. Besides, not every system will have an ftpd

The main issue to over come is how you work with slirp. The "external helper application" mode of slirp is simply not designed for protocols requiring more than one connection.

Getting this to work under the "pipe" interface of SLIRP requires far more than a cooperative FTP daemon, it also requires a new protocol to be defined between SLIRP and this cooperative FTP daemon.. and in such case it is much better to simply stick to the already well-established FTP protocol imho (which calls for port redirection as discussed before).

I don't see this as a difficult problem for a builtin FTP server though,
provided that passive mode is used.

For a built-in FTP server passive or active mode should not matter. You will then be running below the SLIRP TCP socket layer, not standard TCP/IP sockets.

If the ftp server ran on its own ip
address, then qemu could simply set up new servers on new ports for the
new data connections and have the client connect to them.

You already have the router virtual IP address under your (or SLIRP) full control. No need to invent additional addresses imho.

Active mode is a little harder to do right, but thats hard to get right through a NAT connection anyways.

I don't see why active should be much harder than passive. SLIRP already have support for both accepting and making connections both ways. Just use what there is. There will be a somewhat hefty state machinery involved however.. writing an FTP daemon within SLIRP is considerably more complex than the same thing as a stand-alone daemon.

On another note reshapign the already existing (but disabled) rsh emulation to fake a "trusted" login to the host should be pretty trivial, allowing rcp etc to work fine on UNIX hosts. Some small modifications of the existing code is required to grab both usernames (for .rhosts processing), some .rhosts processing for security and also some slight modifications in rsh_exec to fork a shell rather than trying to rsh somewhere else..


reply via email to

[Prev in Thread] Current Thread [Next in Thread]