Hi Daniel.

I'm actually a fan of yours when it comes to support... you're like superman
for mailing lists...

Anyway... as I was saying, I gathered the following logs from his
application (with his permission of course). We already disabled EPSV so we
figured it could've solved the problem. Sadly, it didn't. Lemme show you the
bad logs (BTW, we reupload the same thing if we don't get the curlcode
CURLE_OK):

* Remembering we are in dir /music//BWFTP/766WD-WCANY1634154/583/
* FTP response timeout
* control connection looks dead
* Connection #0 to host crackerjack.dreamhost.com left intact
2007-07-16 16:45:35.204 Bandwagon FTP[16846] Error: FTP response timeout
2007-07-16 16:45:35.204 Bandwagon FTP[16846] Headers {"550 583" = "No such
file or directory"; } and Error FTP response timeout
2007-07-16 16:45:35.204 Bandwagon FTP[16846] Uploaded size: 0
* Examining connection #0 for reuse
* Re-using existing connection! (#0) with host crackerjack.dreamhost.com
* Connected to crackerjack.dreamhost.com (64.111.115.19) port 21 (#0)
* Request has same path as previous transfer
> PASV
* Connect data stream passively
< 226 Transfer complete
* Bad PASV/EPSV response: 226
* Remembering we are in dir /music//BWFTP/766WD-WCANY1634154/583/766WD-
WCANY16341541184618583.mp3
* Uploaded unaligned file size (0 out of 5903550 bytes)
* Connection #0 to host crackerjack.dreamhost.com left intact
2007-07-16 16:45:36.518 Bandwagon FTP[16846] Error: Bad PASV/EPSV response:
226
2007-07-16 16:45:36.518 Bandwagon FTP[16846] Headers {} and Error Bad
PASV/EPSV response: 226
2007-07-16 16:45:36.911 Bandwagon FTP[16846] Uploaded size: 0
* Examining connection #0 for reuse
* Connection #0 seems to be dead!
* Closing connection #0
* About to connect() to crackerjack.dreamhost.com port 21 (#0)
* Trying 64.111.115.19... * connected
* Connected to crackerjack.dreamhost.com (64.111.115.19) port 21 (#0)
< 220 ProFTPD 1.3.1rc2 Server (DreamHost FTP) [64.111.115.19]
> USER hifilyrics
< 331 Password required for hifilyrics
> PASS ******
< 230 User hifilyrics logged in
> PWD
< 257 "/" is the current directory
* Entry path is '/'
> CWD /music
< 250 CWD command successful
> CWD BWFTP
< 250 CWD command successful
> CWD 766WD-WCANY1634154
< 250 CWD command successful
> CWD 583
< 250 CWD command successful
> PASV
* Connect data stream passively
< 227 Entering Passive Mode (64,111,115,19,213,24).
* Trying 64.111.115.19... * connected
* Connecting to 64.111.115.19 (64.111.115.19) port 54552
> TYPE I
< 200 Type set to I
> STOR 766WD-WCANY16341541184618583.mp3
< 150 Opening BINARY mode data connection for
766WD-WCANY16341541184618583.mp3

BTW, as you may see, they're using dreamhost as servers. The logs you've
seen are Cocoa logs, but they are just coded the same way we see it in your
examples. Were the logs clear enough? Should you ask anything about how we
handle curl handles, what we could say is we've done the basics, so nothing
special about coding FTP...

What could we be doing wrong? BTW, this is libcurl v7.16.1, and I dunno if
this has been resolved on the current releases, but I didn't saw anything
related to this after 7.16.1 in your changelogs (at least on the ones I
could understand).

Thanks for the fast response.

On 7/17/07, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Mon, 16 Jul 2007, Jofell Gallardo wrote:
>
> > Bad PASV/EPSV response: 229
> >
> > Searching the net and you mailing list gives us the reason that it might
> be
> > Dreamhost that's causing this. Will disabling EPSV remove this error
> (people
> > keep uploading the same file over and over again) or is it caused by a
> list
> > of reasons?
> >
> > Please tell me if you understand my question. BTW, I just do simple FTP
> > downloads through curl. Nothing fancy.
>
> I understand your question. Recent libcurl should try PASV if EPSV fails
> so
> disabling EPSV _should_ not change anything, although of course there are
> weird servers everywhere so you should probably try that out.
>
> --
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
>
Received on 2007-07-16