Intermittent SSL protocol error using FTPSImpl (General questions)

I have used wodFtpDLXcom for years in a project with historically very good success. I use it for FTPSImplicit sessions, and always have.

Recently, one client started frequently getting Data Socket: SSL protocol error when trying to do a transfer. Repeating the attempt will eventually allow it to work. The control connection on port 990 never seems to be the problem -- it is the data port connection.

It doesn't appear to be a firewall blocking part of the port range used for the data connections, as I have seen the errors on the same port where one has worked from the same client location. (I tell the data port from the last 2 figures in the 227 reply text such as 227 Entering Passive Mode (*************,12,54) which would be port 12 * 256 + 54 or 3126).

Searching the forums I found a thread from 2005, but that user solved the problem by using FTPSimplicit instead of FTPSwithdata, and I already use FTPSimpllicit.

The same code has worked for me for a long time, and all sessions are to the same host and the host software has not changed. The host is running Pure-FTPd [TLS] with Glub Tech FTP Wrapper v3.0.4, like it always has.

With the user where I first saw this, it fails more often than it works. And now I am sometimes seeing it with other users, I am sometimes seeing it but so far works more often than it fails.

Any ideas of where to look or what to try?

Doug

Hi Doug,

Can you please check which version of component you use? Can you please try the latest one?

Also, does anything similiar occur with any other client software (i.e. FileZilla)?

Regards,
Damba

Damba,

Thanks for the quick reply.

Can you please check which version of component you use? Can you please try the latest one?

I am currently using DLL version 2.8.5.425 in com mode, and unfortunately my upgrade rights have lapsed because your DLL works too well and I haven't needed to purchase an upgrade. :)

Note also that it has never failed for me, so to test a newer DLL will require sending it to a user to see what happens. I am not adverse to that, but was looking for some suggestions as to what could cause this.

It doesn't strike me as something wrong with the DLL -- it has worked too well for me for years for that. It seems like some external change, perhaps from Windows Update, or a network configuration at the problem location. However, the IT tech support staff at the building where I have the problem insist it is not from changes on their end.

If I download 2.9.7 to send to the user for testing, are there complications from the fact my upgrade period has lapsed? Won't it require a new license key from my 2.8.x license?

To make matters worse, the email which I used for purchasing years ago is now obsolete -- your records would show me as a different email which I can no longer receive due to an ISP mixup.

Since I am dubious the version has anything to do with it, I'm not looking to repurchase the DLL if I can avoid it.

Doug,

The version that you are using is almost a year old. There were many changes/fixes between that period, so if it was a problem with the compoenent, there is a chance it was resolved.

Since your subscription expired, I would suggest that you try downloading Demo version, just to check if the issue was resolved. If that works, you can choose to extend your subscription (we still allow that, but it has to be extended from the date of expiry. Also, price per year is 20 of the component).

If you decide to try Demo version, make sure you make backup of your old version. Also, in order to distribute demo version, you will need to install the component on your customers machine, since Demo cannot be distributed (as a trial version limit).

As for the error you are receiving, this error is usually thrown when wrong protocol is used (i.e. using SFTP to connect to FTPS server).

You could also try changing between Active/Passive mode? Also, does setting StrictHost property to true help?

Regards,
Damba

Damba,

Since your subscription expired, I would suggest that you try downloading Demo version, just to check if the issue was resolved. If that works, you can choose to extend your subscription (we still allow that, but it has to be extended from the date of expiry. Also, price per year is 20 of the component).

Based on my records, I think my subscription expired Sep 8 2008, so 13 months ago. Do you still allow a renewal? For 40 of the current price?

Also, in order to distribute demo version, you will need to install the component on your customers machine, since Demo cannot be distributed (as a trial version limit).

So what is the recommended way to do this? Have them download and install the demo and rename the current DLL in my application folder so it does not find it first? My installer puts your DLL in the same folder as my application.

Does the demo installer put the DLL in a path where the system would locate it universally? EG WindowsSystem32

These users will need hand holding, so I want to be sure I know what to talk them through.

As for the error you are receiving, this error is usually thrown when wrong protocol is used (i.e. using SFTP to connect to FTPS server).

You could also try changing between Active/Passive mode? Also, does setting StrictHost property to true help?

Yet I know the protocol is right -- the code hasn't changed in a long time, and with repeated attempts it eventually works. That is why my first guess was a partial firewall block on the data port range. That could explain a hit or miss success rate depending on the port assigned.

I have always used passive and StrictHost -- it was the only way I could get things to work at all. But other than these recent failures -- mostly from one location -- it has worked consistently.

My user interface currently does not expose those options -- it runs all the transfers automagically when the user clicks a single button. But I guess I can alter the UI to expose them for testing or something if you think it could help. However, with firewalls in the way I would expect passive and stricthost will both be required.

Doug

Doug,

I replied to on our ticketing system regarding renewal.

As for using demo, customer would need to download and install the component. Once installed, the component files (.dll and .ocx) are placed into C:\Windows\System32 folder and registered.

However, if you decided to extend your subscription, all of the above is unnecessary, since you would use licensed libraries.

Regards,
Damba

However, if you decided to extend your subscription, all of the above is unnecessary, since you would use licensed libraries.

I decided to renew without even having the customer try the demo. Your component is important enough to me that I should keep it current, even if it has run flawless for a long time.

Once I have the user try the update, I'll report back on its effect.

Once I have the user try the update, I'll report back on its effect.

I am now running DLL version 2.9.7.501 and still have the same problem. A few users get this error on occasion but typically work. Just retrying once will generally do it.

For one user, it happens very frequently and it is the rare exception where it works. Yet it is a scripted program so I know the protocol is set right -- the user has no control over it.

The second error which sometimes shows up instead is:

Error 40425: Possible PASV port theft, cannot open data connection.

The server is running Pure-FTPd and I have asked the FTP server host provider if there is a way to disable the port theft check but have not heard back yet.

Any ideas on either problem?

Douglas,

You mention that one user receive error frequently.

Is there any chance he can try same from same machine using some other FTPS client like FIleZilla for example. What happens?

Drazen

Drazen,

Is there any chance he can try same from same machine using some other FTPS client like FIleZilla for example. What happens?

Unfortunately, this user is probably 1500 miles from me and shall we say, computer illiterate. That is why they use a scripted program that does everything for them. :)

Currently there would not be another FTPS capable client on their system. I may be able to arrange trying to get someone else local to them to go there, install a client, and see what happens.

Is that my best course of action here?

Doug,

You can try to use PasvPort Property in your code before Connect Method. PasvPort Property determines outgoing port that will be used with passive data connection.

If 990 is used for your FTPS server you can try with port value 0 and 989. If 21 is used you can try 20 or 0. Of course you can try with some other port that will be open on their firewall.

More help for PasvPort Propert you can find here:
http://www.weonlydo.com/FtpDLX/Help/wodFtpDLXLib~wodFtpDLX~PasvPort.html

If your problem persist you can send us debug file to techsupport@weonlydo.com when error occur.

Here is example how to add DebugFile to your code:
[code]dlx1.DebugFile = c:\debug.txt
dlx1.Connect[/code]

Drazen

Drazen,

You can try to use PasvPort Property in your code before Connect Method. PasvPort Property determines outgoing port that will be used with passive data connection.

So when not zero, it makes it ignore the port received in the 227 response from the server and just try a data connection on the port specified in PasvPort?

I can try that, but that certainly sounds like it should only work if the server is always expecting a data connection on that port. And why would it then send something different in the 227 reply? Also note the same server works for most users, so it isn't like a firewall at the server is blocking the data port.

But I'm game to try anything, so while changing my client code I will make this a configurable option, along with disabling passive mode or strict host mode. Plus add the ability to create the debug file.

If your problem persist you can send us debug file

OK, that sounds like a definitive plan. I'll keep you posted.

Doug,

PasvPort should be used with Passive = True.

When Passive = False you can try with MinDataPort and MaxDataPort Property.

Drazen