|
Hi!
I am awfully sorry that I make a mistake, and I should do my own test
and then say whether it is OK or not. :(
Your analysis is definitely right. The Router need to add a new
masquerading entry for the new connection between the server and
the client, otherwise the client cannot send the ACK packets of
receiving data to the server. The virtual server is different from
the tunneled host, in the tunneled host all the packets will be
redirected
to the single host, in the virtual server there are many servers.
I think the best solution is to add some codes in the ftp_masq_app
module just as you said. However, please keep in mind that let the
original codes works properly while adding new things. So, if the
packet is detected for tunneling (there is a flag, please check
the linux/include/net/ip_masq.h), then parse the PORT command in
the packet, create a new entry if found. If the packet is not for
tunneling, then let the original code do it (parse the PASV command).
Peter, you have been doing a good job, thank you and good luck,
Wensong
Peter Ke{e wrote:
>
> Hi!
>
> No, not really. I can connect to the ftp server (whichever is chosen
> by the VS router), I can logon, send my password and set some options.
> But when I want to transfer a file, the whole thing locks up.
>
> What happens is the following:
> Before each file transfer starts, the ftp client sends the ftp server
> an IP addres and IP port number on which the client (!) is listenning.
> This is done by the ftp 'PORT' command. Then the client requests a
> file transfer. The server opens a tcp socket and connects it to the
> IP address/port specified by the client. In other words, the server
> connects to the client.
>
> So in order to thansfer a file, a completely new TCP connection is
> created between server and client. This connection is called a DATA
> connection. It is a different pair of ports, but the IP addresses
> usually remain the same.
>
> Of course the TCP packets send by the server across the DATA
> connection easily reach the client, but the TCP layer on the client
> must also send some packets back to the server in response. When
> such an IP packet arrives, it arrives to the VS router, which must
> decide, where to route those packets. The VS router does not know
> what to do with those packets and simply lets them be handled by
> the local host.
>
> If I set up a local host VS configuration, each time the local host
> (the VS router itself) is chosen to play the server role, the ftp
> works fine. But when any other server is chosen, the connection
> simply freezes whenever I send a GET/PUT/DIR command.
>
> So I think if the 'PORT' commands would be intercepted by the router
> and a proper masquerading entry inserted into the hash table, the
> ftp server could work fine. Now this is the theory I would like to
> prove and I wouldn't mind spending some time on it. But it would
> make it much easier to let the ftp_masq_app reside in a module...
>
> Any comments/ideas?
>
> Cheers,
> Peter
>
>
> P.S. What is the situation with the 2.2.X kernels. Did anyone have
> a peek at the 2.2.x masquerading code - does it differ a lot?
> How much work would it take? Any candidates?
>
I haven't heard that anybody volunteer for it. Although I downloaded
the 2.2.x kernel and built kernel for some hosts, I haven't check
the 2.2.x masquerading code, I don't know how it differs.
|
