Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

[Henrik Nordstrom]

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
> installed.

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..

Regards
Henrik