On Wed, 8 Jun 2005, Jim C. Brown wrote:
Next to impossible to do portably. I am not sure how user-net port redirection
even enters the picture - once the FTP daemon is set up, the guest sees
the FTP server on the host (admittedly on a nonstandard port, but is that
such a big deal?).
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.
FTP unfortunately doesn't fit in the user-net pipe framework due to it's
(ftp) broken design (data channel mess).
Can you explain what you mean here?
The user-net pipe support when seeing a new TCP connection to the piped
port (as used for the SMB server) forks a child process and connects the
TCP connection via a pipe to this child process sort of as if it was
started by inetd.
Problem is that FTP uses more than one TCP connection (the main control
channel, plus one data channel per transfer) and this isn't supported by
the slirp pipe support. For this kind of protocols you have to use port
mapping or forwarding.
The real FTP server only works because it is running on a real TCP/IP,
allowing it to open additional ports which is bidirectionally reachable
for the client (direction depending on which PORT/PASV mode is used)
Regards
Henrik
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel