Hi,

first, many thanks to all for your help.

Yes, I had to patch the curl to ignore ip provided with pasv command,
until the remote side will fix their ftps servers/fw. As i have
mentioned here, I have limitted control over the remote side.
The version of curl, I have tried the original one (curl-7.12.1) for
with the patch was provided so as the latest one (curl-7.14.0). Both
behaive the same.
Re, network traice, I can provide remote side trace so as mine, if
this helps. What I have seen from the log, my curl sends STOR a few
secs after remote side just disconnects, but my curl don't even notice
the remote disc.
I'll prepare the trace dumps from both sides and post it.

Thx,
N.

On 8/9/05, Daniel Stenberg <daniel-curl_at_haxx.se> wrote:
> On Mon, 8 Aug 2005, Norbert Novotny wrote:
>
> > This is the verbose out put:
> > curl -E ./SSL/CL.pem:sslpwd --disable-epsv -T TEST.TXT
> > --ftp-ignore-pasv-ip -v -u ftp.box:mypwd --ftp-ssl
>
> ^^^
>
> Using a custom patched curl are we? ;-)
>
> What curl version is this based on?
>
> > < 220 Welcome to XFB Gateway FTP server
> >> USER ftp.box
> > < 331 Send password please
> >> PASS mypwd
> > < 230 User logged in, proceed
> >> PBSZ 0
> > < 503 Bad sequence of command
>
> Sorry, but your server seem to not like the PBSZ command that curl sends. Curl
> should really have added an informational here that this means it'll continue
> with its assumed default setup, which in the ftps:// URL case means it
> believes it will use SSL for the data connection as well...
>
> > < 200 Command okay
> >> STOR TEST.TXT
>
> ... but now, my guess is that the server and curl don't agree on the SSL
> status of the data connection and thus it "hangs" there when curl wants to
> negotiate SSL and the server doesn't.
>
> Seem likely? I believe a network traffic capture might be able to tell if
> we're on the right track here or not.
>
> --
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
>
Received on 2005-08-13