Bug 9439

Summary:	Can't use default port for data transfers
Product:	[Retired] Red Hat Linux	Reporter:	Steve Muir <sjmuir>
Component:	ftp	Assignee:	Thomas Woerner <twoerner>
Status:	CLOSED WONTFIX	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	pekkas
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-01-27 16:36:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Steve Muir 2000-02-14 21:30:32 UTC

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 18:04:58 UTC

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 23:24:20 UTC

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-21 00:28:30 UTC

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...