Re: Strange problems with FTP - please, help!

I think your prb is at data connection
but not at port range but at adress negociation... read bellow

1* When ftp server will transfer data and try to open a data connection
in passive mode, the client do open the connection based on information 
the server sends to it
the server send a range of available port and its IP adress
i think your problem is not the port range but the ip adress

the server has its own adress
behind that, you have a router with a public ftp adress

the ftp client connects to th public adress
but what about openning a data transfer on the IP the server sends back 
(not necesseraly the public IP but perhaps the true server ip adress)

wu-ftp has an option for it :
<<
passive address 1.2.3.4 192.168.1.0/24
 >>
(extracted from my /etc/wu-ftp/ftpaccess config file)
as you can see, the server will advertise to the ftp client the adress 
1.2.3.4 (on the subnet 192.168.1.0),
this way the ftp client will negociate a port toward THIS ip adress 
while the real IP adress of the server is something like 192.9.200.0

this configuration has to be done on the ftp server

try to know the exact ftp server you are using (220 rohrpostfix FTP 
server is of no help)
and see in manpage or on the web if you can change such setting

<<
The ZyXEL had the same problem at the beginning, but then I
configured it to forward *everything* to the server's IP from the outside.
Then it suddenly worked.
>>

You encountered the same problem : your server used to send its own IP 
adress, after you modification, it advertise the public IP adress, not 
its real/internal/private one

u get the trick ?

2* Try to know the exact ftp package you are using :
to get you ftp package name, try this :
    rpm -qa | grep -i ftp
to retreive the package owner of a file, do :
    # rpm -qf <file>
    # rpm -qf /usr/sbin/wu.ftpd
    wu-ftpd-2.6.1-16
try to see what file your inet or xinetd.conf file launch :
    # grep ftp /etc/xinetd.conf
    # namei <file>    # usefull to retreive the real file following symlinks
then do :
    # rpm -ql <file>

tell us your ftpd package as we could search also if this option exists

hth bye


Rainer Hantsch wrote:

>Hello!
>
>At one of my customers, a FTP server had to be installed. It is the one which
>is included in SuSE 8.0 / Kernel 2.4.18-4GB:
>220 rohrpostfix FTP server (Version 6.5/OpenBSD, linux port 0.3.2)
>
>What has to be mentioned, is:
>The FTP server is behind a NETOPIA router (with ISDN fallback). The router
>does IP-masquerading between its internal IP 192.168.1.2 and its official IP,
>the server has a WAN-NIC (192.168.1.1).
>
>
>Here a session transscript from my workstation (SuSE 8.0, also behind a
>router with IP-masquerading):
>---<snip>------------------------------------------------
>Connected to XXXXXXXXXXXXXXXXX
>Name (XXXXXXXXXXXXX:rainer): anonymous
>331 Guest login ok, type your name as password.
>Password: ***********
>230 Guest login ok, access restrictions apply.
>Remote system type is UNIX.
>Using binary mode to transfer files.
>ftp> ls
>229 Entering Extended Passive Mode (|||17742|)
>200 EPRT command successful.
>435 Can't build data connection: Illegal seek.
>ftp> quit
>221 Goodbye.
>rainer@miraculix:~>
>---<snap>------------------------------------------------
>
>
>As you can see, the login is possible, but when I enter a command, no data
>connection can be established. (Happens with all commands!).
>The same happens when several people (not only me!) try to transfer data from
>their Windows-PCs (also behind routers), so this cannot be dependend on my
>local configuration.
>
>When I use xFTP instead (the one which is included in SuSE Linux), it is no
>problem to connect and transfer data. It works fine!!!
>
>
>Before this netopia-router was installed, a ZyXEL 310 router was there. But it
>had to be replaced because it allowed no ISDN fallback and got extreme
>problems with ADSL stability (because Telecom changed something in their
>system). The ZyXEL had the same problem at the beginning, but then I
>configured it to forward *everything* to the server's IP from the outside.
>Then it suddenly worked.
>
>What I *guess* is: There is a problem establishing the data connection
>from most clients, because they use upper ports, while xFTP seems to work
>different. But I could not find out the difference at all.
>
>
>Does somebody have fixed such a problem? It is really urgent and I must get it
>working ASAP.
>
>mfg
>
>  Ing. Rainer Hantsch
>
>
>  
>