Outbound port on sockets

[bmearns]

Is it possible to specify which port to use as the outbound port on a
connection? I have the IP address and port number for the computer I'm
trying to connect to (not listening for), but it's expecting my
connection on a certain port.

Specifically, I'm trying to write an FTP host, and I'm trying to
implement the PORT command. From everything I've read, the client
supplies the IP address and port number for where I'm supposed to
connect to send it data (like a LISTing), and it's expecting me to
connect over port 20. If anyone is familiar with FTP and can tell me
whether this is true or not, whether I really need to go out on port
20, I'd appreciate it, as well.

Thanks.

[Fredrik Lundh]

"bmearns" wrote:

Specifically, I'm trying to write an FTP host, and I'm trying to
implement the PORT command. From everything I've read, the client
supplies the IP address and port number for where I'm supposed to
connect to send it data (like a LISTing), and it's expecting me to
connect over port 20. If anyone is familiar with FTP and can tell me
whether this is true or not, whether I really need to go out on port
20, I'd appreciate it, as well.

PORT means that the client is asking the server to connect to the given
IP/port combination; see:

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

the port number used by the server for this connection is irrelevant.

</F>

[Diez B. Roggisch]

bmearns schrieb:

Is it possible to specify which port to use as the outbound port on a
connection? I have the IP address and port number for the computer I'm
trying to connect to (not listening for), but it's expecting my
connection on a certain port.

Specifically, I'm trying to write an FTP host, and I'm trying to
implement the PORT command. From everything I've read, the client
supplies the IP address and port number for where I'm supposed to
connect to send it data (like a LISTing), and it's expecting me to
connect over port 20. If anyone is familiar with FTP and can tell me
whether this is true or not, whether I really need to go out on port
20, I'd appreciate it, as well.

AFAIK you neither can't do that nor need it. The PORT commands purpose
is to tell where the server can connect to - but the client makes no
assumptions over the source port of that connection. Let alone NAT and
other things could come into your way.

If firewalls are a problem, use PASV.

Diez

[billie]

bmearns wrote

Is it possible to specify which port to use as the outbound port on a
connection? I have the IP address and port number for the computer I'm
trying to connect to (not listening for), but it's expecting my
connection on a certain port.

Specifically, I'm trying to write an FTP host, and I'm trying to
implement the PORT command. From everything I've read, the client
supplies the IP address and port number for where I'm supposed to
connect to send it data (like a LISTing), and it's expecting me to
connect over port 20. If anyone is familiar with FTP and can tell me
whether this is true or not, whether I really need to go out on port
20, I'd appreciate it, as well.

Thanks.

This isn't correct.
If you send a PORT command you're telling server to establish a
connection with you, not the contrary. In this case, even if you are an
FTP client, you temporary ACCEPT an outbound connection from the FTP
server.
The right format of a FTP PORT command is:

PORT x,x,x,x,y,z

....where x(s) represents your IP address in dotted form and (x * y) the
TCP port you bind.
For further informations you can check RFC959 or take a look at ftplib
in standard module library. Also in twisted you can find a lot of
useful code in the module protocols.ftp.

[billie]

The right format of a FTP PORT command is:

>
PORT x,x,x,x,y,z

...where x(s) represents your IP address in dotted form and (x * y) the
TCP port you bind.

Sorry, I wanted to say: (y * z)

[bmearns]

Thanks for all the responses. I understood what the PORT command was
for, but I've been seeing alot of doc online that only mentions going
outbound on port 20 for data connections, so I thought maybe that was
my problem.

Sorry if this is the wrong spot to follow up on this not-so-much-python
matter. Does anyone know of an appropriate news group?
I'm trying to get through a router and Norton Internet security, using
my homebrewed python FTP server and Internet Explorer as my client
(I've also tried microsoft's FTP command line client). I'm able to go
back and forth on the command socket, no problem, but after the client
issues a PORT, I try to connect to it, and time out. I'm becoming
increasingly convinced that it's a firewall/router issue because if I
connect to my server as localhost, instead of my outside IP address, I
can connect fine.

I've tried disabling Internet security, but that doesn't help. I
suspect the problem is port forwarding from the router, but I don't
know what the port numbers will be, so how can I set up forwarding?

Any help is greatly appreciated. I've been banging my head against the
wall for hours.

-Brian

[bmearns]

Quick follow up, I'm able to connect to other external FTP sites behind
my firewall and router, no problem.

-Brian
bmearns wrote:

Thanks for all the responses. I understood what the PORT command was
for, but I've been seeing alot of doc online that only mentions going
outbound on port 20 for data connections, so I thought maybe that was
my problem.

Sorry if this is the wrong spot to follow up on this not-so-much-python
matter. Does anyone know of an appropriate news group?
I'm trying to get through a router and Norton Internet security, using
my homebrewed python FTP server and Internet Explorer as my client
(I've also tried microsoft's FTP command line client). I'm able to go
back and forth on the command socket, no problem, but after the client
issues a PORT, I try to connect to it, and time out. I'm becoming
increasingly convinced that it's a firewall/router issue because if I
connect to my server as localhost, instead of my outside IP address, I
can connect fine.

I've tried disabling Internet security, but that doesn't help. I
suspect the problem is port forwarding from the router, but I don't
know what the port numbers will be, so how can I set up forwarding?

Any help is greatly appreciated. I've been banging my head against the
wall for hours.

-Brian

[Sergei Organov]

"bmearns" <bm*****@coe.neu.eduwrites:

Quick follow up, I'm able to connect to other external FTP sites behind
my firewall and router, no problem.

You've been told already to implement PASV command in your server (then
client will be able to use so called passive mode).

-- Sergei.

[bmearns]

Passive mode is implemented, the client isn't trying to use it.
Besides, that doesn't really help me anyway, all it means is that I
have to resolve port forwarding for the server, instead of for the
client.

I think what this basically comes down to is that either with PASV or
PORT, there's a relatively arbitrary port number being specified, and I
can't figure out how to get my router to forward it since I don't know
what it will be in advance, short of forwarding all the 64 thousand
some odd valid ports.

The thing that gets me is that I can connect to the other FTP servers,
and (according to the responses echoed by the command line FTP client),
they're using PORT, not PASV. So somehow, my client is specifying some
arbitrary port for the server to connect to, and that port is actually
being forwarded through my router.

-Brian

Sergei Organov wrote:

"bmearns" <bm*****@coe.neu.eduwrites:

Quick follow up, I'm able to connect to other external FTP sites behind
my firewall and router, no problem.

You've been told already to implement PASV command in your server (then
client will be able to use so called passive mode).

-- Sergei.

[bmearns]

It's actually 256*y + z
billie wrote:

The right format of a FTP PORT command is:

PORT x,x,x,x,y,z

...where x(s) represents your IP address in dotted form and (x * y) the
TCP port you bind.

Sorry, I wanted to say: (y * z)

[Steve Holden]

billie wrote:
[...]

The right format of a FTP PORT command is:

PORT x,x,x,x,y,z

....where x(s) represents your IP address in dotted form and (x * y) the
TCP port you bind.

That's actually x*256 + y - tou're makling a 16-bit unsigned integer
from two bytes.

For further informations you can check RFC959 or take a look at ftplib
in standard module library. Also in twisted you can find a lot of
useful code in the module protocols.ftp.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Diez B. Roggisch]

bmearns schrieb:

Passive mode is implemented, the client isn't trying to use it.
Besides, that doesn't really help me anyway, all it means is that I
have to resolve port forwarding for the server, instead of for the
client.

I think what this basically comes down to is that either with PASV or
PORT, there's a relatively arbitrary port number being specified, and I
can't figure out how to get my router to forward it since I don't know
what it will be in advance, short of forwarding all the 64 thousand
some odd valid ports.

But you can restrict the numbers of ports the server will use to a
certain range! It's common for ftp to allow only for so many connections
at the same time, so reserve a port-range of 20 or so for your server
and configure the router to forward them.

The thing that gets me is that I can connect to the other FTP servers,
and (according to the responses echoed by the command line FTP client),
they're using PORT, not PASV. So somehow, my client is specifying some
arbitrary port for the server to connect to, and that port is actually
being forwarded through my router.

No idea how that happens, but there are protocol aware fire walls.

Diez

[bmearns]

But you can restrict the numbers of ports the server will use to a

certain range! It's common for ftp to allow only for so many connections
at the same time, so reserve a port-range of 20 or so for your server
and configure the router to forward them.

Thanks, I think that'll have to be my work around till I can find more
information about this. I do still consider it a work around, though,
I'd like to be able to use both PORT and PASV and I'm entirely
convinced it's possible.

All the same, it's a good suggestion. Thank you. Now do you know how I
(as the server) can force clients to use PASV, instead of PORT?

-Brian

[Fredrik Lundh]

bmearns wrote:

All the same, it's a good suggestion. Thank you. Now do you know how I
(as the server) can force clients to use PASV, instead of PORT?

have you tried returning a suitable error code ? (502 should be a good
choice).

(and before you proceed, reading

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

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

</F>

[Bryan Olson]

Diez B. Roggisch wrote:

bmearns schrieb:

>Is it possible to specify which port to use as the outbound port on a
connection?

[...]

>Specifically, I'm trying to write an FTP host, and I'm trying to
implement the PORT command.

AFAIK you neither can't do that nor need it.

It's not the issue here, but to specify the outgoing port
call bind(('', portnum)) before connect().
--
--Bryan

[Diez B. Roggisch]

Bryan Olson schrieb:

Diez B. Roggisch wrote:

>bmearns schrieb:

>>Is it possible to specify which port to use as the outbound port on a
connection?

[...]

>>Specifically, I'm trying to write an FTP host, and I'm trying to
implement the PORT command.

AFAIK you neither can't do that nor need it.

It's not the issue here, but to specify the outgoing port
call bind(('', portnum)) before connect().

I wasn't aware of that. Cool.

Diez

[Grant Edwards]

On 2006-09-15, Diez B. Roggisch <de***@nospam.web.dewrote:

>>>Is it possible to specify which port to use as the outbound port on a
connection?

[...]

>>>Specifically, I'm trying to write an FTP host, and I'm trying to
implement the PORT command.

AFAIK you neither can't do that nor need it.

It's not the issue here, but to specify the outgoing port
call bind(('', portnum)) before connect().

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

--
Grant Edwards grante Yow! .. this must be what
at it's like to be a COLLEGE
visi.com GRADUATE!!

[Sergei Organov]

Grant Edwards <gr****@visi.comwrites:

On 2006-09-15, Diez B. Roggisch <de***@nospam.web.dewrote:

>>>>Is it possible to specify which port to use as the outbound port on a
connection?
[...]
Specifically, I'm trying to write an FTP host, and I'm trying to
implement the PORT command.

AFAIK you neither can't do that nor need it.

It's not the issue here, but to specify the outgoing port
call bind(('', portnum)) before connect().

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

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(data_source)) < 0)
ERROR;
...
if(connect(s,
(struct sockaddr *)&info->def_addr,
sizeof(struct sockaddr_in)) < 0
)
ERROR;

I've no idea what "multi-homing problems" are, but maybe it gives you
some hint?

-- Sergei.

[Grant Edwards]

On 2006-09-15, Sergei Organov <os*@javad.comwrote:

>>>It's not the issue here, but to specify the outgoing port
call bind(('', portnum)) before connect().

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

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(data_source)) < 0)
ERROR;
...
if(connect(s,
(struct sockaddr *)&info->def_addr,
sizeof(struct sockaddr_in)) < 0
)
ERROR;

I've no idea what "multi-homing problems" are, but maybe it gives you
some hint?

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.

But, like I said, is very vague, and I suppose some client
implementor could have read it as the server must use the
default data port as the source port for a data connection.

--
Grant Edwards grante Yow! Ha ha Ha ha Ha ha
at Ha Ha Ha Ha -- When will I
visi.com EVER stop HAVING FUN?!!

[Steve Holden]

Grant Edwards wrote:

On 2006-09-15, Sergei Organov <os*@javad.comwrote:

>>>>>It's not the issue here, but to specify the outgoing port
>call bind(('', portnum)) before connect().

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

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(data_source)) < 0)
ERROR;
...
if(connect(s,
(struct sockaddr *)&info->def_addr,
sizeof(struct sockaddr_in)) < 0
)
ERROR;

I've no idea what "multi-homing problems" are, but maybe it gives you
some hint?

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.

But, like I said, is very vague, and I suppose some client
implementor could have read it as the server must use the
default data port as the source port for a data connection.

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. If you look in
/etc/services you'll likely see that port 21 is identified as "ftp" or
"ftp-control" and 20 as "ftp-data".

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.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Grant Edwards]

On 2006-09-15, Steve Holden <st***@holdenweb.comwrote:

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

--
Grant Edwards grante Yow! Yow!! That's a GOOD
at IDEA!! Eating a whole FIELD
visi.com of COUGH MEDICINE should
make you feel MUCH BETTER!!

[Jorgen Grahn]

On Thu, 14 Sep 2006 18:21:39 +0200, Fredrik Lundh <fr*****@pythonware.comwrote:

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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!

[Bryan Olson]

Grant Edwards wrote:

Diez B. Roggisch wrote:

[Bryan Olson had written:]

>>It's not the issue here, but to specify the outgoing port
call bind(('', portnum)) before connect().

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

[Bryan Olson]

Steve Holden wrote:

Grant Edwards wrote:

>>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))
--
--Bryan

[Steve Holden]

Bryan Olson wrote:

Steve Holden wrote:

>>Grant Edwards wrote:

>>>>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
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Paul Rubin]

Steve Holden <st***@holdenweb.comwrites:

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?