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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
