Outbound port on sockets

[Grant Edwards]

I don't know what "multi-homing problems are either".
Apparently there must be some ftp clients that require the
source port for the data connection to be port 20.

The RFC is pretty vague. It does say the server and clinet but
must "support the use of the default data port [port 20]" or
something like that. But, it's not all all clear to me what
that is supposed to mean. My reading is that they must support
the default port as the destination port for a data connection
untill it's been changed by receipt of a PORT command.

Standard (port-mode) FTP has the client send a PORT command to the
server when data transfer is required. The server then makes a
connection to the indicated port from its own port 20.

I agree that's certainly the way it seems to work. When I read
the RFC, I couldn't tell if it intended to require that the
source port be 20. It almost sounded like it meant that the
data connection destination was 20 unless a PORT command was
received, but that wouldn't make much sense.

Passive mode was introduced so that the server is not required
to make a connection inbound to the client, as more and more
firewalls were interposed at the perimeter of networks,
blocking the inbound requests to clients from servers.

I suspect that the reason for the comment is simply that the
connection out from the server is being bound to the same
interface (*IP address*) that the inbound request arrived on.
That way it's less likely that the data stream will be routed
differently from the control (port 21) stream.

I think that's probably right. It just dawned on me that
"multi-homed" refers to having more than one network interface.

 

[Jorgen Grahn]

bmearns wrote: ....
(and before you proceed, reading

http://cr.yp.to/ftp/security.html

is also a good idea.

And RFC1123, and any number of FTP-related RFCs. There's even one fairly
early RFC that encourages everyone to use the PASV command exclusively -- I
still cannot see why he has to mess around with PORT.

are you 110% sure that you absolutely definitely
have to use FTP rather than HTTP/WebDAV or somesuch).

Yeah; quoting RFC1123, from back in 1989:

| Internet users have been unnecessarily burdened for years by deficient
| FTP implementations. Protocol implementors have suffered from the
| erroneous opinion that implementing FTP ought to be a small and
| trivial task. [---]

It seems to me (with my tiny knowledge of FTP) that if he has problems with
PORT/PASV, that's nothing compared to the difficulty of implementing
different data transfer modes and so on.

On the other hand, implementing FTP is a cool programming project ;-)

/Jorgen

 

[Bryan Olson]

Diez B. Roggisch wrote: [Bryan Olson had written:]

I wasn't aware of that. Cool.

It's an interesting thing to know, but I've been doing TCP
stuff for many years and never run across a situation where
it's something I needed to do. If somebody in this thread
actually does need to do it, I'd be curious bout why...

One made-up example: Unix traditionally restricts port
numbers below 1024 so that only root can use them. One might
have a white-list of trusted Unix machines, and insist
requests come from a port below 1024.

I used the empty string for the address, which Python's socket
module resolves to INADDR_ANY, but you can also use bind() to
set a particular adapter.

 

[Bryan Olson]

Well, one of ftpd implementations I have here (C code from RTEMS) does
this:

/* anchor socket to avoid multi-homing problems */
data_source = info->ctrl_addr;
data_source.sin_port = htons(20); /* ftp-data port */
if(bind(s, (struct sockaddr *)&data_source, sizeof( [...]
if(connect(s, [...]

[...]
I suspect that the reason for the comment is simply that the connection
out from the server is being bound to the same interface (*IP address*)
that the inbound request arrived on. That way it's less likely that the
data stream will be routed differently from the control (port 21) stream.

That still doesn't explain why they pass 20 as the port number.
To specify an IP address, but let the system choose an arbitrary
open port, use:

bind((specific_IP, 0))

 

[Steve Holden]

Well, one of ftpd implementations I have here (C code from RTEMS) does
this:

/* anchor socket to avoid multi-homing problems */
data_source = info->ctrl_addr;
data_source.sin_port = htons(20); /* ftp-data port */
if(bind(s, (struct sockaddr *)&data_source, sizeof( [...]
if(connect(s, [...]

[...]

I suspect that the reason for the comment is simply that the connection
out from the server is being bound to the same interface (*IP address*)
that the inbound request arrived on. That way it's less likely that the
data stream will be routed differently from the control (port 21) stream.

That still doesn't explain why they pass 20 as the port number.
To specify an IP address, but let the system choose an arbitrary
open port, use:

bind((specific_IP, 0))

As I mentioned if the posting you made a partial quote from, the
original specification of port-mode FTP has the server making a data
connection from its port 20 to the client port identified by the
client's PORT command.

regards
Steve

 

[Paul Rubin]

As I mentioned if the posting you made a partial quote from, the
original specification of port-mode FTP has the server making a data
connection from its port 20 to the client port identified by the
client's PORT command.

This is TCP port 20? What happens if the server wants to have more
than one concurrent outgoing connection?