On 16/07/07, Daniel Stenberg <daniel_at_haxx.se> wrote:
> Since the connecting of the second data connection is done rather differently
> in the two forks (PASV vs PORT) I would rather say that such a switch could be
> easier done by doing this code like this:
>
> 1) detect the PASV failure, set the internal option for the connection that
> PASV is disabled and PORT is mandated
>
> 2) set data->reqdata.newurl to the same URL and return back, and allow the
> follow-redirection logic to start over the fetch
>
> 3) the "redirected" fetch will re-use the connection since it is still alive
>
> 4) this time it'll use PORT
>
> --
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
>

Thanks for the pointers, unfortunately I need some more help.

Here is the patch I applied (against curl-7.16.5-20070718):

--- curl-7.16.5-20070718\lib\ftp.c 2007-07-18 04:00:02.000000000 +0100
+++ curl-7.16.5-20070718-2\lib\ftp.c 2007-07-18 12:49:27.519984000 +0100
@@ -1715,6 +1715,14 @@ static CURLcode ftp_state_pasv_resp(stru
     /* remain in the FTP_PASV state */
     return result;
   }
+ else if(ftpcode == 502) {
+ data->set.ftpport = "-";
+ data->set.ftp_use_port = 1;
+ infof(data, "disabling PASV usage\n");
+ data->reqdata.newurl = data->set.set_url;
+ state(conn, FTP_STOP);
+ return CURLE_OK;
+ }
   else {
     failf(data, "Bad PASV/EPSV response: %03d", ftpcode);
     return CURLE_FTP_WEIRD_PASV_REPLY;

And here is the updated output:

> EPSV
* Connect data stream passively
< 500 command not recognised.
* disabling EPSV usage
> PASV
< 502 Command not implemented.
* disabling PASV usage
> TYPE A
< 200 Type set to ASCII.
> NLST
< 150 opening data connection
[...60 second pause...]
* Timeout while waiting for server connect
* Connection #0 to host 172.x.x.x left intact
* FTP command PORT failed
> QUIT
< 425 couldn't open data connection
* Closing connection #0

I think I'm getting closer to a solution, but I can't work out what to do next.

Dan.
Received on 2007-07-18