cURL / ftps / Glub -- server did not report OK, got 150

[Ripstick]

Hi Gang -

I have been asked to initiate an ftps connection from my HP-UX 11.11 system to a customer running Glub (Glub Tech Secure FTP Wrapper v2.5.9.1) on a Windows system in order to upload files to them. Although they are requiring us to make this FTPS connection, they only offer client options and support for Windows-based servers, and offer no solution or support for UNIX servers.

HP Support suggested installing OpenSSL and cURL as a solution. Having successfully used this combination in the past on another UNIX system I had no reason to doubt I could get it to work.

Unfortunately, I cannot begin to count the weeks I've been working on this with my customer and cannot for the life of me figure out where/why it's failing.

From the command line I execute:

curl -K command.txt

This is the configuration file (command.txt) that I'm currently using with cURL...

#---------------#
# command.txt #
#---------------#

--ftp-ssl
--disable-eprt
--cacert /opt/openssl/certs/cacert.pem
--url ftp://ftps.glubsite.com:21/send/
-u user:password
-T "testfile.txt"
-k
-v
-Q "+LIST"

#---------------#
# END OF FILE #
#---------------#

Please note that cURL is using SSL 3 by default. I've tried SSL 2 but it fails with:

* error:1406D0CB:SSL routines:GET_SERVER_HELLO:peer error no cipher
* Closing connection #0
curl: (35) error:1406D0CB:SSL routines:GET_SERVER_HELLO:peer error no cipher

Clearly SSL 3 is in use, so I'm good there.

When I run this cURL command I am able to connect to the ftps site and log on successfully. However, the file transfer itself fails with the following error:

curl: (18) server did not report OK, got 150

It hangs at this point and then disconnects 30 seconds later. Please see the attached file for the complete session log.

I cannot tell you how many different options and combinations I've tried, and I keep coming back to this combination because it appears to get me the furthest. I've had the customer look into things are their end and nothing that they've done has changed the transfer behaviour as seen in the attached log.

Is there something else I'm missing or could this still be an issue on the customer's end?

Any and all insight will be much appreciated!

Rick