> > --snip--
> > * About to connect() to
> > onlinefiletransfer.suntrust.com port 20021 (#0)
> > * Trying 167.181.46.51... connected
> > * Connected to onlinefiletransfer.suntrust.com
> > (167.181.46.51) port 20021 (#0)
> [...]
> > > PASV
> > * Connect data stream passively
> > < 227 Entering Passive Mode (10,49,53,32,78,82)
> > * Trying 10.49.53.32... Timed out
> > * couldn't connect to host
> > --snip--
>
> The host responds to the PASV ccommand with the
> address 10.49.53.32, so
> that's what curl connects to. Since that address is
> an internal address that clients cannot connect
> to, the server is broken.
Aw Sweet! It work now. This is the problem I had
been struggling with for 2 days before I post the
first email here. I wasn't sure if it was a cURL bug
or not when I saw the 2nd host/ip address that don't
match.

> Luckily, this brokenness is common enough that curl
> has an option to overcome
> it: --ftp-skip-pasv-ip That tells curl to ignore
> what address the server
> says to use and just connect to the original IP
> address.
That's a good thing we have a workaround to the
problem. I can't image how we could survive without
that curl option.

Dan, you have been a great help and I thank you for
that. I didn't know that the SunTrust's server is
broken in the first place. Thanks man!

cURL rulz!! :-)

Scott
Received on 2006-11-24