First, thanks to Rob Cotrone
be sure that your firewall as the port > 1024 open !! or the ftp server won't be able to change port
as I see you haven't open the port 20 !
you known port 20 is ftp-data , the port used to transfert datas ! so you will be able to open session but not to receive data ro list a directory !
Thanks for the reply, Matthieu!
I double-checked this, and I tried disabling all port blocking and
restrictions from my firewall while running the test again. I had exactly
the same result.
The firewall had gotten in my way once already, and I was hoping you'd
found it, but it dosen't seem to be.
On Wed, 13 Jun 2001 13:11:28 +0200, Marius Tomaschewski
Hi!
Use the newest version from
ftp://ftp.suse.com/pub/projects/proxy-suite/
the bind/connect problems and also other bugs should be fixed now. Because of NAT, you may also set the TranslatedAddress (I'm not sure, if I've understand your network bellow).
Thanks to you too, Marius, for replying. It's very appreciated. I was using a copy of 1.7 from the OpenBSD ports tree. I went and downloaded the version from SuSE, and tried it, just to make sure I was current. The files seemed - except for the couple of tweaks needed to get it to build - identical. The one from the SuSE ftp server had the same problems as before, too. I don't think I need TranslateAddress. The proxy should be the one who talks to each side, and it is running on the firewall, which can get to both internal and external address directly. I was hoping this was an easy problem you'd seen before. I guess not. I've been looking at the debug output and sources a little more. I'm going to go through the output in great detail, along with my understanding of what those lines mean. If I'm confused someplace, please let me know. My first question when looking at the debug output was, "What is Cli-Ctrl, Cli-Data, Srv-Ctrl, and Srv-Data?" I think I figured that out. In the output, there is a line: 09:47:28 < 348> Srv-Ctrl is 192.168.0.178:21 This is creating the link to the real FTP server. The debug code refers to that at Srv-Ctrl. Cli-Ctrl should be the client control channel. Cli-Data should be the client data channel, and Srv-Data should be the server data channel. The terms 'client' and 'server' are being used from the proxy's point of view. The client I'm using does Active FTP - I'm using the Win2K command line client, because it's predictable. Let me make sure I know how active FTP works; The client connects to the server on port 21. This is the control channel. When data needs to be sent, the client sends a PORT command, with it's IP address and a port number on which it is listening. The server connects to the client on this port. Now, if I go through the debug output very carefully, I see the following things happen: In the case of the proxy, client does a PORT, which the proxy recieves: 09:47:39 < 348> gets Cli-Ctrl 0=158.252.208.8: 23 bytes 'PORT 158,252,208,8,6,41' 09:47:39 < 348> from User-PI (0): cmd='PORT' arg='158,252,208,8,6,41' 09:47:39 < 348> printf Cli-Ctrl 0=158.252.208.8: 30 bytes '200 PORT command successful.' 09:47:39 < 348> USER-INF 'PORT 158.252.208.8:1577' from 158.252.208.8 In ftp-cmds.c, in the function cmds_port(), the proxy verifies that command, and stores the IP address and port in ctx.cli_addr, and ctx.cli_port. It then returns a success to the client. This makes sense. The client then sends the NLST command: 09:47:40 < 348> gets Cli-Ctrl 0=158.252.208.8: 4 bytes 'NLST' 09:47:40 < 348> from User-PI (0): cmd='NLST' arg='' 09:47:40 < 348> USER-INF 'NLST' from 158.252.208.8 The proxy opens a socket to listen on, and then passes a PORT command back to the real FTP server, advising it of that: 09:47:40 < 348> listen: Srv-Data (fd=4) 192.168.0.250:44026 09:47:40 < 348> printf Srv-Ctrl 3=192.168.0.178: 28 bytes 'PORT 192,168,0,250,171,250' 09:47:40 < 348> TECH-INF 'PORT 192.168.0.250:44026' for 158.252.208.8 The FTP server acknowledges that: 09:47:40 < 348> gets Srv-Ctrl 3=192.168.0.178: 28 bytes '200 PORT command successful.' 09:47:40 < 348> from Server-PI (3): '200 PORT command successful.' The FTP server has a data connection to the proxy. The proxy should now make a data connection to the client. This is from the debug logs: 09:47:40 < 348> try to con-bind Cli-Data to 192.168.0.250:20 09:48:54 < 348> TECH-ERR can't connect Cli-Data for 158.252.208.8 (errno=60 [Connection timed out]) Now, it looks like it's trying to bind the client data port to 192.168.0.250:20. In ftp-client.c, in the function client_xfer_fireup(), it seems to make the connection for the active FTP connection. It calls societ_d_connect with ctx.cli_addr and ctx.cli_port again. The debug output says this is 192.168.0.250, port 20. Why is it not the client address/port of 158.252.208.8:1577 that was stored in the PORT command above? 192.168.0.250 is the proxy-server's own IP address. Have I misunderstood? In active FTP, a PORT command from the client tells the server to connect to the client, who listens. The proxy needs to connect back to the client. Instead, it appears to be trying to connect to it's self. I am still poking around to see if I can figure things out any better. Any other suggestions anyone has are more than welcome, and I shall try them out. Thanks fr any response, and for wading through my long and somewhat rambling messages. -- Louis Erickson - wwonko@rdwarf.com - http://www.rdwarf.com/~wwonko/ Bumper sticker: "All the parts falling off this car are of the very finest British manufacture"