Bug 9439 - Can't use default port for data transfers
Can't use default port for data transfers
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: ftp (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-14 16:30 EST by Steve Muir
Modified: 2007-04-18 12:26 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-27 11:36:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Muir 2000-02-14 16:30:32 EST
If one disables use of the PORT command (using sendport) ftp is supposed
to receive data on the default port, which is defined by RFC 959 to be the
same port number as the control connection was opened on.  In order to
open such a socket ftp uses the SO_REUSEADDR option on the new socket
before trying to bind the default port number.  However, Linux 2.2 also
requires that the existing socket with the same port number i.e., the
control connection, must also have that option set if both sockets have
the same local IP address (see lines 255--269 in kernel source file
net/ipv4/tcp_ipv4.c).  Since ftp doesn't set that option on the control
socket, the bind() call for the data socket fails.  Modifying ftp to set
the SO_REUSEADDR option on the control socket fixes this problem.
Comment 1 Pekka Savola 2000-07-15 14:04:58 EDT
This is an issue with ftp-0.17-3 from Rawhide too.

I believe this might be a little more widespread; the fix isn't trivial.

In Linux is does:
----
ftp> sendport
Use of PORT cmds off.
ftp> ls
ftp: bind: Address already in use
----

After modifying the source a bit, it gets a little further:
----
ftp> sendport
Use of PORT cmds off.
ftp> ls
150 Opening ASCII mode data connection for '/bin/ls'.
total 4
d--x--x--x   2 root  root  1024 Sep  2  1999 bin
d--x--x--x   2 root  root  1024 Sep  2  1999 etc
drwxr-xr-x   2 root  root  1024 Sep  2  1999 lib
drwxr-sr-x  12 root  ftp   1024 Jul 14 12:27 pub
226 Transfer complete.
ftp> ls
425 Can't build data connection: Cannot assign requested address.
ftp>
----

Ie. the first command works, the rest crash.

_This happens with BSD's ftp too_ (from which Linux version was derived from).
So, perhaps the server can't set SO_REUSEADDR properly?

If you use passive mode with sendport, it'll work it won't be 'sendport' anyway
due to it's passive nature..

If you know any more about this, please notify us/ftp developers. :)

Comment 2 Bernhard Rosenkraenzer 2001-01-20 18:24:20 EST
Can't reproduce this on 7.
It might be a server issue though - what server were you trying to access?
Comment 3 Pekka Savola 2001-01-20 19:28:30 EST
This can't be detected on RHL7 because passive mode is enabled by default. Using 'passive' before sendport this
can be seen (using the latest rawhide ftp here):

# ftp linftp
Connected to linftp.xxx.fi.
220 linftp.xxx.fi FTP server (Version 6.5/OpenBSD, linux port 0.3.2) ready.
Name (linftp:root): ftp
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> passive
Passive mode off.
ftp> sendport
Use of PORT cmds off.
ftp> ls
ftp: bind: Address already in use
ftp> quit
221 Goodbye.

All the other daemons I've tested this with seem to exhibit the same symptoms, 
at least up to 'bind' part (unless modified).


Not that there's much point for this anymore as passive mode is used by default...

Note You need to log in before you can comment on or make changes to this bug.