EPSV vs PASV

By default, libcurl always tries EPSV first, then PASV. However, some FTP
sites don't like EPSV and it's impossible to connect unless you disable it.

Such servers are completely broken. libcurl attempts to disable EPSV when it
gets a problem with it and retries with PASV instead.

Completely broken servers don't act reasonably so it is hard to come up with
reasonable ways to work with them. But of course, if anyone has ideas for
improvements then let's discuss them!

So what approach should be used to be able to connect to any site?

libcurl has a sensible default approach IMHO.

Is there a way to query FTP site for preferred command before setting an
appropriate libcurl option?

I think the problem isn't always in the particular FTP server but in middle-
boxes along the way. The firewall/NAT on the client side and the firewall/load
balancer/whatever on the server side. As FTP needs them to be state aware to
function perfectly, some old and broken ones will mess up on commands they
don't understand. EPSV has only existed in an RFC since 1998 after all! B)

--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Leo

2011-01-19 16:16:50 UTC

Thanks, Daniel!

That clarifies what happens under the hood. And, obviously, curl
connects perfectly to majority of servers.

However, I still wonder what to do from the practical point of view...

Right now I have several FTP servers to which any FTP client connects
instantly.

libcurl will only connect to them instantly with EPSV disabled.
Otherwise it never connects, or it takes really long time.

These servers belong to newspapers and are being used quite extensively.

So... I guess here's the questions I have:

-Do other FTP clients do something that libcurl doesn't?

-Or do they use reversed approach, i.e. try PASV first, then EPSV?

-Is there a way to connect to such servers without disabling EPSV? (But
then it can't be used universally).

-Am I missing something?

Thanks,
Leo

Post by Leo
By default, libcurl always tries EPSV first, then PASV. However, some
FTP sites don't like EPSV and it's impossible to connect unless you
disable it.

Such servers are completely broken. libcurl attempts to disable EPSV
when it gets a problem with it and retries with PASV instead.
Completely broken servers don't act reasonably so it is hard to come
up with reasonable ways to work with them. But of course, if anyone
has ideas for improvements then let's discuss them!

Post by Leo
So what approach should be used to be able to connect to any site?

libcurl has a sensible default approach IMHO.

Post by Leo
Is there a way to query FTP site for preferred command before setting
an appropriate libcurl option?

I think the problem isn't always in the particular FTP server but in
middle- boxes along the way. The firewall/NAT on the client side and
the firewall/load balancer/whatever on the server side. As FTP needs
them to be state aware to function perfectly, some old and broken ones
will mess up on commands they don't understand. EPSV has only existed
in an RFC since 1998 after all! B)

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Daniel Stenberg

2011-01-19 19:07:46 UTC

Post by Leo
Right now I have several FTP servers to which any FTP client connects
instantly.

After reading your mail I realized you're here talking about connecting the
data connection, and I assume you mean in a passive manner.

Post by Leo
libcurl will only connect to them instantly with EPSV disabled.

A failed EPSV should be fairly quick. If it takes time I think it indicates
something wrong, either in the server-side or in the client-side. I can't rule
out any bugs/problems in libcurl, but I'm not aware of any in the current
version.

Post by Leo
Otherwise it never connects, or it takes really long time.

You talk about this in generic terms but in generic terms libcurl already
works fine. You need to be specific, exact and show us details of exactly what
the servers do when libcurl sends exactly what commands to them. Probably with
timing info.

Post by Leo
-Do other FTP clients do something that libcurl doesn't?

Perhaps, or even most likely. libcurl is implemented independently and we
follow the FTP standard specs and it has been tried against live FTP servers
for over a decade. We have never copied how other clients do, so I would
expect other clients to have smaller to larger deviances in how they interact
with servers. The issue here is of course to figure out if there are any
important differences.

You can probably figure that out without too much problems using wireshark or
similar. Many FTP clients features a debug mode that displays the exact
commands and responses that are sent and received. Then you can compare those
with what libcurl sends and receives.

Post by Leo
-Or do they use reversed approach, i.e. try PASV first, then EPSV?

I don't know.

Post by Leo
-Is there a way to connect to such servers without disabling EPSV? (But then
it can't be used universally).

I don't know. I think we need more details and facts first.

Post by Leo
-Am I missing something?

Yes: the fact that we don't like top-postings on this mailing list. Please
trim your quotes and write your mail below the pieces of the quotes that you
think are necessary to provide content to your reply.

--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Leo

2011-01-20 03:37:19 UTC

On 1/19/11 2:07:46 PM, Daniel Stenberg wrote:

Thanks and I apologize for top-posting - just didn't pay attention.

I've been using curl for over 5 years already, never had any problems,
that's why I never really needed this group. :) It's been easy enough to
use to never require any assistance, rock solid and problem-free. That's
why I never really had to investigate or understand in depth what
EPSV/PASV do and why.

Post by Leo
-Is there a way to connect to such servers without disabling EPSV?
(But then it can't be used universally).

I don't know. I think we need more details and facts first.

OK, here's an example of one such FTP server. curl can't connect without
disabling EPSV: it waits for over a minute then fails. Cyberduck
connects without problems, and so does curl with EPSV disabled.

I'm on Mac OS X 10.5.8 with libcurl 7.16.3

Below are 3 logs:

1. Cyberduck connects as is.
------------------------

220 Canwest File Transfer Server
FEAT
530 Please login with USER and PASS.
USER calgaryadupload
331 Password required for calgaryadupload.
PASS ********
230 Login OK. Proceed.
PWD
257 "/" is current folder.
NOOP
200 Command OK.
SYST
215 UNIX Type: L8
STAT /
211-FTP server status:
Connected to 99.231.98.177 at Wednesday, January 19, 2011, 14:39:34
Logged in as CA\calgaryadupload
TYPE: ASCII, STRUcture: File, transfer MODE: Stream
No data connection.
211 End of status
PASV
227 Entering Passive Mode (204,187,151,151,16,78)
LIST -a
150 Opening ASCII mode data connection for file list.
drwxrw-rw- 1 user group 0 Jan 19 13:49 Admin
226 Transfer complete. 62 bytes transferred. 62 bps.

2. libcurl fails with EPSV
--------------------

* About to connect() to ftp.postmedia.com port 21 (#0)
* Trying 204.187.151.151... connected
* Connected to ftp.postmedia.com (204.187.151.151) port 21 (#0)
< 220 Canwest File Transfer Server

Post by Daniel Stenberg
USER calgaryadupload

< 331 Password required for calgaryadupload.

Post by Daniel Stenberg
PASS <********>

< 230 Login OK. Proceed.

< 257 "/" is current folder.
* Entry path is '/'

Post by Daniel Stenberg
EPSV

* Connect data stream passively
< 229 Entering Extended Passive Mode (|||4212|)

<some 75 sec wait here>

* Trying 204.187.151.151... Operation timed out
* couldn't connect to host
* got positive EPSV response, but can't connect. Disabling EPSV

< 425 Data connection already open.
* Bad PASV/EPSV response: 425
* Remembering we are in dir ""
* Connection #0 to host ftp.postmedia.com left intact
curl: (13) Bad PASV/EPSV response: 425

Post by Daniel Stenberg
QUIT

< 221 Service closing control connection.
* Closing connection #0

3. libcurl connects instantly with EPSV disabled
---------------------------------------

* About to connect() to ftp.postmedia.com port 21 (#0)
* Trying 204.187.151.151... connected
* Connected to ftp.postmedia.com (204.187.151.151) port 21 (#0)
< 220 Canwest File Transfer Server

Post by Daniel Stenberg
USER calgaryadupload

< 331 Password required for calgaryadupload.

Post by Daniel Stenberg
PASS <********>

< 230 Login OK. Proceed.

< 257 "/" is current folder.
* Entry path is '/'

* Connect data stream passively
< 227 Entering Passive Mode (204,187,151,151,16,230)
* Trying 204.187.151.151... connected
* Connecting to 204.187.151.151 (204.187.151.151) port 4326

Post by Daniel Stenberg
TYPE A

< 200 Type set to A.

Post by Daniel Stenberg
LIST

< 150 Opening ASCII mode data connection for file list.
* Maxdownload = -1
drwxrw-rw- 1 user group 0 Jan 19 13:49 Admin
* Remembering we are in dir ""
< 226 Transfer complete. 62 bytes transferred. 62 bps.
* Connection #0 to host ftp.postmedia.com left intact

Post by Daniel Stenberg
QUIT

< 221 Service closing control connection.
* Closing connection #0

Thanks,
Leo

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Michael Wood

2011-01-20 07:10:14 UTC

Hi

On 20 January 2011 05:37, Leo <***@rogers.com> wrote:
[...]

Post by Leo
OK, here's an example of one such FTP server. curl can't connect without
disabling EPSV: it waits for over a minute then fails. Cyberduck connects
without problems, and so does curl with EPSV disabled.
I'm on Mac OS X 10.5.8 with libcurl 7.16.3

That is a very old version of libcurl. I suggest you upgrade it
before trying anything else.

[...]

Post by Leo
2. libcurl fails with EPSV
--------------------
* About to connect() to ftp.postmedia.com port 21 (#0)
* Trying 204.187.151.151... connected
* Connected to ftp.postmedia.com (204.187.151.151) port 21 (#0)
< 220 Canwest File Transfer Server

Post by Leo
USER calgaryadupload

< 331 Password required for calgaryadupload.

Post by Leo
PASS <********>

< 230 Login OK. Proceed.

Post by Leo
PWD

< 257 "/" is current folder.
* Entry path is '/'

Post by Leo
EPSV

* Connect data stream passively
< 229 Entering Extended Passive Mode (|||4212|)
<some 75 sec wait here>
* Trying 204.187.151.151... Operation timed out
* couldn't connect to host
* got positive EPSV response, but can't connect. Disabling EPSV

Post by Leo
PASV

This looks like some sort of firewall/NAT issue rather than anything
libcurl can do anything about. There is no way for libcurl to know
that the network between the client and the server is broken. Clearly
the server doesn't know either or it would not have replied with "229
Entering Extended Passive Mode (|||4212|)".

Post by Leo
< 425 Data connection already open.

OK, so the server thinks there's nothing wrong with EPSV, but libcurl
couldn't connect, so when libcurl retried with PASV, the server says
"Hey! What are you doing? You already asked me to open a port for
EPSV and now you want me to open another one for PASV???"

I think the only way libcurl can deal with this is to close the
control channel after the EPSV failed and then open a new one when
trying the PASV. Unless maybe an ABOR command would work. But, first
try the latest version of libcurl, because it might already do
something like this. I have not checked.

Post by Leo
* Bad PASV/EPSV response: 425
* Remembering we are in dir ""
* Connection #0 to host ftp.postmedia.com left intact
curl: (13) Bad PASV/EPSV response: 425

Post by Leo
QUIT

< 221 Service closing control connection.
* Closing connection #0

--
Michael Wood <***@gmail.com>
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Daniel Stenberg

2011-01-20 13:58:48 UTC

Post by Michael Wood

Post by Leo
< 425 Data connection already open.

OK, so the server thinks there's nothing wrong with EPSV, but libcurl
couldn't connect, so when libcurl retried with PASV, the server says "Hey!
What are you doing? You already asked me to open a port for EPSV and now
you want me to open another one for PASV???"
I think the only way libcurl can deal with this is to close the control
channel after the EPSV failed and then open a new one when trying the PASV.
Unless maybe an ABOR command would work. But, first try the latest version
of libcurl, because it might already do something like this. I have not
checked.

You're right, after the failed connect I suppose libcurl needs to do either an
ABOR or a complete close, and it doesn't do any of that now even in the
current version.

However, judging from that output, it wouldn't completely solve this issue as
it takes 75 seconds to fail anyway. That failure seems to be network-related
(like a firewall) and just about the only way to avoid that problem is to not
even try EPSV...

--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Leo

2011-01-24 19:58:48 UTC

Post by Michael Wood

Post by Leo
< 425 Data connection already open.

OK, so the server thinks there's nothing wrong with EPSV, but libcurl
couldn't connect, so when libcurl retried with PASV, the server says
"Hey! What are you doing? You already asked me to open a port for
EPSV and now you want me to open another one for PASV???"
I think the only way libcurl can deal with this is to close the
control channel after the EPSV failed and then open a new one when
trying the PASV. Unless maybe an ABOR command would work. But, first
try the latest version of libcurl, because it might already do
something like this. I have not checked.

You're right, after the failed connect I suppose libcurl needs to do
either an ABOR or a complete close, and it doesn't do any of that now
even in the current version.
However, judging from that output, it wouldn't completely solve this
issue as it takes 75 seconds to fail anyway. That failure seems to be
network-related (like a firewall) and just about the only way to avoid
that problem is to not even try EPSV...

Daniel and Michael:

Thanks a lot for getting to the bottom of it! I'll get back to this
topic soon when a few crazy days are over. :)

Leo
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Leo

2011-02-05 19:23:01 UTC

Post by Michael Wood
OK, so the server thinks there's nothing wrong with EPSV, but libcurl
couldn't connect, so when libcurl retried with PASV, the server says
"Hey! What are you doing? You already asked me to open a port for
EPSV and now you want me to open another one for PASV???"
I think the only way libcurl can deal with this is to close the
control channel after the EPSV failed and then open a new one when
trying the PASV. Unless maybe an ABOR command would work. But, first
try the latest version of libcurl, because it might already do
something like this. I have not checked.

You're right, after the failed connect I suppose libcurl needs to do
either an ABOR or a complete close, and it doesn't do any of that now
even in the current version.
However, judging from that output, it wouldn't completely solve this
issue as it takes 75 seconds to fail anyway. That failure seems to be
network-related (like a firewall) and just about the only way to avoid
that problem is to not even try EPSV...

Hi,

I'm back with the EPSV vs PASV issue - thanks again Daniel and Michael
for making this issue more clear.

So here's my findings so far:

-About 15 servers that don't like EPSV were reported. curl tries to
connect with EPSV, then switches to PASV after a 75 sec wait and either
fails (as in my previous example) or connects. If EPSV is disabled, curl
connects with no problems.

Here's an example of successful connection after waiting 75 sec and
switching to PASV:

* About to connect() to 145.243.189.65 port 21 (#0)
* Trying 145.243.189.65... connected
* Connected to 145.243.189.65 (145.243.189.65) port 21 (#0)
< 220 FTP Server 205 ready.

Post by Daniel Stenberg
USER FBISP

< 331 Please specify the password.

Post by Daniel Stenberg
PASS <***>

< 230 Login successful.

< 257 "/"
* Entry path is '/'

Post by Daniel Stenberg
EPSV

* Connect data stream passively
< 229 Entering Extended Passive Mode (|||24440|)

<75 sec wait>

* Trying 145.243.189.65... Operation timed out
* couldn't connect to host
* got positive EPSV response, but can't connect. Disabling EPSV

< 227 Entering Passive Mode (145,243,189,65,131,198)
* Trying 145.243.189.65... connected
* Connecting to 145.243.189.65 (145.243.189.65) port 33734

Post by Daniel Stenberg
TYPE A

< 200 Switching to ASCII mode.

Post by Daniel Stenberg
LIST

< 150 Here comes the directory listing.
* Maxdownload = -1
-rw-r--r-- 1 ftp ftp 2129482 Jan 30 17:38
GES_KU_STU300111_019.JPG
-rw-r--r-- 1 ftp ftp 2170928 Jan 30 17:39
GES_KU_STU300111_020.JPG
drwxr-xr-x 2 ftp ftp 1024 Jan 30 03:10 MSSP_Pauli-K?ln
drwxr-xr-x 2 ftp ftp 512 Jan 30 08:35 Pauli_K?ln
drwxr-xr-x 3 ftp ftp 1536 Jan 30 17:17 _gsdata_
-rw-r--r-- 1 ftp ftp 1641858 Jan 30 16:36
rudel_vfb-freiburg35.jpg
-rw-r--r-- 1 ftp ftp 421952 Jan 30 17:39
rudel_vfb-freiburg38.jpg
-rw-r--r-- 1 ftp ftp 588405 Jan 30 16:38
rudel_vfb-freiburg39.jpg
* Remembering we are in dir ""
< 226 Directory send OK.
* Connection #0 to host 145.243.189.65 left intact

Post by Daniel Stenberg
QUIT

< 221 Goodbye.
* Closing connection #0

-One server that does exactly the opposite: it doesn't accept PASV. curl
can only connect with EPSV enabled. I know that this server is behind a
small Firewall and it's Windows 2008 64 bit Microsoft FTP Service from
IIS 7 (if it makes any difference).

Here's a log of connection attempt with EPSV disabled:

* About to connect() to www.xeen3d.de port 21 (#0)
* Trying 87.193.152.189... connected
* Connected to www.xeen3d.de (87.193.152.189) port 21 (#0)
< 220 ----------------------- xeen3d -------------------------

Post by Daniel Stenberg
USER ftptest

< 331 Password required for ftptest.

Post by Daniel Stenberg
PASS <***>

< 230-Welcome to xeen3d FTP Server
< Directory has 28,281,733,120 bytes of disk space available.
< 230 User logged in.

< 257 "/" is current directory.
* Entry path is '/'

* Connect data stream passively
< 227 Entering Passive Mode (87,193,152,189,19,141).

<75 sec wait>

* Trying 87.193.152.189... Operation timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

-Other FTP clients I tried (Cyberduck and Transmit) connect to all sites
with no problems.

I'm on Mac OS X 10.5.8, still with libcurl 7.16.3 - but from what Daniel
said I understand that later versions wouldn't change anything in this area.

So is there a way to make curl choose the correct method (EPSV/PASV)
automatically? Am I missing something? (BTW, the same question applies
to choosing between passive and active mode).

I LOVE curl, but obviously I want to understand why I can't achieve
something that other FTP clients can - and if I can achieve this, then
what am I doing wrong?

Thanks,
Leo

Michael Wood

2011-02-05 20:16:18 UTC

Hi

On 5 February 2011 21:23, Leo <***@rogers.com> wrote:
[...]

-About 15 servers that don't like EPSV were reported. curl tries to connect
with EPSV, then switches to PASV after a 75 sec wait and either fails (as in
my previous example) or connects. If EPSV is disabled, curl connects with no
problems.
Here's an example of successful connection after waiting 75 sec and
* About to connect() to 145.243.189.65 port 21 (#0)
* Trying 145.243.189.65... connected
* Connected to 145.243.189.65 (145.243.189.65) port 21 (#0)

[...]

EPSV

* Connect data stream passively
< 229 Entering Extended Passive Mode (|||24440|)
<75 sec wait>
* Trying 145.243.189.65... Operation timed out
* couldn't connect to host
* got positive EPSV response, but can't connect. Disabling EPSV

PASV

< 227 Entering Passive Mode (145,243,189,65,131,198)
* Trying 145.243.189.65... connected

[...]

This looks like there's some sort of NAT device or firewall that
understands how to deal with "227 Entering Passive Mode
(145,243,189,65,131,198)" from the server, but doesn't understand how
to deal with "229 Entering Extended Passive Mode (|||24440|)". The
server itself clearly doesn't have a problem with EPSV.

-One server that does exactly the opposite: it doesn't accept PASV. curl can
only connect with EPSV enabled. I know that this server is behind a small
Firewall and it's Windows 2008 64 bit Microsoft FTP Service from IIS 7 (if
it makes any difference).
* About to connect() to www.xeen3d.de port 21 (#0)
* Trying 87.193.152.189... connected
* Connected to www.xeen3d.de (87.193.152.189) port 21 (#0)

[...]

PASV

* Connect data stream passively
< 227 Entering Passive Mode (87,193,152,189,19,141).
<75 sec wait>
* Trying 87.193.152.189... Operation timed out
* couldn't connect to host

Again here the server seems happy with PASV, but the firewall/NAT
device doesn't like it.

-Other FTP clients I tried (Cyberduck and Transmit) connect to all sites
with no problems.

Well, it seems unlikely to me that Cyberduck and Transmit both know in
advance whether the firewalls and/or NAT devices between you and an
arbitrary server will allow PASV vs. EPSV to work, so they must not be
using either PASV or EPSV, but rather active mode FTP (i.e. the PORT
command.) Of course the PORT command can also fail in exactly the
same way if there are broken firewalls or NAT devices between you and
the server, so I don't see how there can be any universally correct
answer to your problem.

Have you tried "--ftp-port -" with the servers you need to talk to?
Are you always running this from the same client or are multiple
clients involved? If multiple clients are involved, then the firewall
on the client becomes more important when using --ftp-port, because
the server will have to make a connection back to the client and the
client's firewall might not allow the incoming connection from the
server.

I'm on Mac OS X 10.5.8, still with libcurl 7.16.3 - but from what Daniel
said I understand that later versions wouldn't change anything in this area.
So is there a way to make curl choose the correct method (EPSV/PASV)
automatically?

No, I don't think so. If the server rejected EPSV or PASV then
libcurl could know immediately that there was a problem and switch to
the other one (or maybe to PORT). Because this problem is caused by
something in between the client and the server and the only way to
know it didn't work is to try and wait for a certain amount of time
before giving up, there's no correct answer.

You could try contacting the people who look after the network where
each server lives and convince them that there is a problem and hope
they fix it. You could also try using --ftp-port and see if that
helps. Otherwise you could build up a list of known servers and the
options that are known to work with them and then be prepared to
update that list when things change. You could perhaps update the
list automatically if you detect a timeout with EPSV for a particular
server and that PASV works for example.

Am I missing something? (BTW, the same question applies to
choosing between passive and active mode).

Indeed :)

I LOVE curl, but obviously I want to understand why I can't achieve
something that other FTP clients can - and if I can achieve this, then what
am I doing wrong?

Well in order to answer that question, it is necessary to find out
what these other FTP clients are doing differently. Perhaps you can
capture the network traffic between the client and server when running
these other FTP clients and use Wireshark to see what they do
differently from libcurl.

Leo

2011-02-09 20:26:55 UTC

Thanks for the detailed analysis, Michael.

Post by Michael Wood
Have you tried "--ftp-port -" with the servers you need to talk to?
Are you always running this from the same client or are multiple
clients involved? If multiple clients are involved, then the firewall
on the client becomes more important when using --ftp-port, because
the server will have to make a connection back to the client and the
client's firewall might not allow the incoming connection from the
server.

Yes, I did try active mode ("--ftp-port -") just in case, and it didn't
work with the servers that dislike EPSV. It just gets to this point and
hangs there:

* Connect data stream actively

Post by Michael Wood
TYPE A

< 200 TYPE is now ASCII

Post by Michael Wood
LIST

I did some research and it's a known issue with the active mode.

Anyway I thought that active mode is a thing of the past and used very
rarely (that's at least my experience). Some 3 years ago I worked at a
large Canadian ad agency and we had over a thousand FTP destinations
(publications, service providers etc.), and only 2 or 3 required active
mode. With the current project I only heard about one site that required
active mode in the last 2 years.

That's also why I doubt that other FTP clients use active mode. As far
as I understand, passive mode is the widely accepted default.

Post by Michael Wood

Post by Leo
I LOVE curl, but obviously I want to understand why I can't achieve
something that other FTP clients can - and if I can achieve this, then what
am I doing wrong?

Here's two Cyberduck logs for the servers I described before. Cyberduck
connects to both of them instantly.

Do these logs help understanding anything?

1. This server doesn't like EPSV:

220 FTP Server 205 ready.
FEAT
211-Features:
EPRT
EPSV
MDTM
PASV
REST STREAM
SIZE
TVFS
211 End
USER FBISP
331 Please specify the password.
PASS ********
230 Login successful.
PWD
257 "/"
NOOP
200 NOOP ok.
SYST
215 UNIX Type: L8
STAT /
213-Status follows:
-rw-r--r-- 1 ftp ftp 283240 Nov 20 17:02
.pureftpd-upload.4ce7eeed.15.245f.5858c934
drwxr-xr-x 2 ftp ftp 1024 Feb 06 06:30
starpress_ball_des_sports
213 End of status

2. This server only likes EPSV and dislikes PASV:

220 ----------------------- xeen3d -------------------------
FEAT
211-Extended features supported:
LANG EN*
UTF8
AUTH TLS;TLS-C;SSL;TLS-P;
PBSZ
PROT C;P;
CCC
HOST
SIZE
MDTM
REST STREAM
211 END
USER ftptest
331 Password required for ftptest.
PASS ********
230-Welcome to xeen3d FTP Server
Directory has 28,280,451,072 bytes of disk space available.
230 User logged in.
OPTS UTF8 ON
200 OPTS UTF8 command successful - UTF8 encoding now ON.
PWD
257 "/" is current directory.
NOOP
200 NOOP command successful.
SYST
215 Windows_NT
STAT /
213-status of /:
drwxrwxrwx 1 owner group 0 Dec 11 2010
aspnet_client
-rwxrwxrwx 1 owner group 76464 Dec 8 2008
nosferatu.php
-rwxrwxrwx 1 owner group 930 Jan 3 0:10 web.config
213 End of status.

As a last test, I tried to connect with Firefox, and it could not
connect to the site that requires EPSV - which makes me think that
whatever FTP engine Firefox uses, it has EPSV disabled by default.

Post by Michael Wood
You could try contacting the people who look after the network where
each server lives and convince them that there is a problem and hope
they fix it. You could also try using --ftp-port and see if that
helps. Otherwise you could build up a list of known servers and the
options that are known to work with them and then be prepared to
update that list when things change. You could perhaps update the
list automatically if you detect a timeout with EPSV for a particular
server and that PASV works for example

Post by Leo
Am I missing something? (BTW, the same question applies to
choosing between passive and active mode).

Indeed :)

Thanks - so at this point, I think that I'll just do this:

-Disable EPSV by default: it looks like it will work in almost all cases.

-Hardcode that one site that requires EPSV and the one that requires
active mode.

Not very elegant, but if it works for now...

I may also add a pop-up menu with 3 connection mode choices:

Default
Passive (EPSV)
Active

and advise users to try to change the mode if the connection could not
be established.

But still I'm curious if those Cyberduck logs help understand how it
connects to both sites seemingly automatically?

Thanks,
Leo

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Daniel Stenberg

2011-02-09 21:37:17 UTC

Post by Leo
STAT /

...

Post by Leo
But still I'm curious if those Cyberduck logs help understand how it
connects to both sites seemingly automatically?

It works without doing PASV or EPSV when doing directory listings by the STAT
command as shown up here. STAT sends contents over the control connection
instead of over a separate data connection (a method that libcurl doesn't yet
support).

If you do a file transfer instead of a directory listing it might act
differently.

--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Leo

2011-02-11 04:05:45 UTC