Feature Requests item #1754793, was opened at 2007-07-16 15:59
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350976&aid=1754793&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
>Group: None
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Daniel Cater (djc0)
Assigned to: Daniel Stenberg (bagder)
Summary: No graceful failure from PASV command

Initial Comment:
When trying to connect passively to a server which only supports active connections, libcurl returns CURLE_FTP_WEIRD_PASV_REPLY and closes the connection.

There should be a way to fallback to an active connection.

When EPSV fails, libcurl gracefully falls back to PASV.

My example is using an embedded FTP server on a piece of hardware. This is how it goes:

* About to connect() to 192.168.0.2 port 21 (#0)
* Trying 192.168.0.2... * connected
* Connected to 192.168.0.2 (192.168.0.2) port 21 (#0
< 220 FTP Server Ready...
> USER user
< 331 Password required for user user.
> PASS pass
< 230 User logged in.
> PWD
< 257 "/root"
* Entry path is '/root'
> EPSV
* Connect data stream passively
< 500 command not recognised.
* disabling EPSV usage
> PASV
< 502 Command not implemented.
* Bad PASV/EPSV response: 502
* Connection #0 to host 192.168.0.2 left intact
* FTP: unknown PASV reply
> QUIT
< 221 Closing connection ... goodbye.
* Closing connection #0

You can see that the EPSV failure is handled OK, but the PASV failure means the end of the connection.

RFC 959 lists the following possible responses to PASV:

PASV
                  227
                  500, 501, 502, 421, 530

I think that "502 Command not implemented." should not cause CURLE_FTP_WEIRD_PASV_REPLY. It is not "weird", merely stating that the server does not support passive connections.

This can be avoided by setting CURLOPT_FTPPORT to "-" but this is not ideal. If I don't know whether the server supports PASV or not, I would prefer it to try PASV first, then fall-back to active (PORT) like happens for EPSV.

I tried to patch the code at ftp.c:1718 but I couldn't solve it. I will try again later.

"CURLE_FTP_WEIRD_PASV_REPLY (13)

libcurl failed to get a sensible result back from the server as a response to either a PASV or a EPSV command. The server is flawed. "

Is an active-only server really "flawed"? Are all servers required to support PASV?

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2007-07-16 23:55

Message:
Logged In: YES
user_id=1110
Originator: NO

Moved to the feature-request tracker.

If you want to discuss implementation details or approaches, please
consider using the curl-library mailing list for that.

----------------------------------------------------------------------

Comment By: Daniel Cater (djc0)
Date: 2007-07-16 23:00

Message:
Logged In: YES
user_id=1843236
Originator: YES

OK, I've changed it to a feature request. I had a look at using
conn->bits.ftp_use_port and conn->bits.ftpport but I couldn't work out how
to change from PASV to PORT. state(conn, FTP_PORT) didn't seem to do much.
I thought data->set.tcpconnect might help but unfortunately not. I hardly
understand the workings so I was just guessing really. This would be really
useful for me, as I work with a lot of servers, some that support PASV and
some that don't. I don't want to sacrifice PASV capability for the servers
that support it just so that the servers that don't support it work.

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2007-07-16 18:39

Message:
Logged In: YES
user_id=236775
Originator: NO

RFC959 section 5.1 says that PASV is optional, so it looks like the server
is fine. However, curl isn't doing anything wrong here, either. It might be
useful to automatically fall back to PORT if PASV fails, but that's a new
feature, not a bug.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350976&aid=1754793&group_id=976
Received on 2007-07-16