EldoS | Feel safer!

Software components for data protection, secure storage and transfer

SFTP download of larger files fails with WSFTP 7.1

Posted: 06/04/2009 05:18:33
by Frank Munsberg (Standard support level)
Joined: 06/04/2009
Posts: 49

I'm having a hard time downloading files from a WSFTP 7.1 Server with the current 7.0.156 SBB Release.

Originally I was using some client I developed but it is reproducible via the SimpleSFTP demo. My client uses that component under the hood.

Things to do:

-Setup FTP Server and user
-put some large file on ftp server (like the ftp server setup.exe itself)
-connect via simplesftp client demo
-download large file
-watch download fail

Error codes are a rather random. Sometimes I get error 105, 103, 10058 or 10054. 10058 seems most frequent here. Afterwards something in the FTP server seems to be broken because I can't connect anymore and get error code 10061 or 10058. Even connecting with a separate FTP client like Filezilla fails after that.

The FTP Server is running on a dedicated Windows XP SP3 machine.

Using the Sophisticated Client demo yielded similar results but it didn't seem to kill the FTP Server itself as I could still connect and download files with Filezilla after an error occurred.

Setting the transfer rate limit of the client to a measly 1024 didn't help and even if it did, there wouldn't be much of a production use possible with that slow speed would it?

I'm kind of clueless what to do/try now.

Posted: 06/04/2009 06:08:52
by Eugene Mayevski (Team)

1) What is "lager" file? How large it is?
2) Did you check the article in the knowledgebase? Did you try all the described steps?

Sincerely yours
Eugene Mayevski
Posted: 06/04/2009 08:55:08
by Frank Munsberg (Standard support level)
Joined: 06/04/2009
Posts: 49

Oh, I forgot the filesize, sorry. The file in question was about 35MB in size.
In the meantime I tried an older version of WS_FTP Server 6.11 (with SSH) that matches our live environment with similar results.

I've read the document about transfer aborts that you kindly linked, thanks for pointing me there.
Since the connection does not close silently but with an error, my guess is that it is not related to idle timeouts like stated in the KB document.

The simplesftp sample catches the OnError Event so every error that happens should display.

The output seems to be consistent this time.

The Transfer starts and transfers the first seemingly 24576 bytes and then aborts with the following errors
Error 105
Error during download: Connection lost (error code is 10058)

105 means ERROR_SSH_INVALID_MAC according to the Errorcode Reference.
10058 should be some winsock error meaning "Cannot send after socket shutdown"

On any following .Open() calls in the sample I get:
Connection failed due to exception: Connection failed (error code is 10061)

10061 is a plain winsock connection refused which makes sense because the SSH Service of WS_FTP crashed in the meantime. After I start that service on the FTP Server machine I can log in again and crash the SSH Service again with a transfer.

I tried around a bit and enabled ASCIIMode which should effectively kill any non-ASCII files according to the specs.
Out of some reason that is beyond me, all files did transfer correctly up or down. Right now I transferred a 1.4GB zip file that was still intact after being transferred with ASCII Mode. Also .pdf or .txt files seemed alright after the transfer.

If it's possible to make the regular transfer without ASCII Mode work I'd be a lot happier.

Posted: 06/04/2009 09:31:59
by Mykola Olshevsky (Basic support level)
Joined: 07/07/2005
Posts: 442

It looks strange, that ASCII mode works ok, but binary not. Possibly, the problem is on the server side (misconfiguration, or software bugs..). Have you checked the same issue with other SFTP client (WinSCP for example)?
Also, please try to disable SFTP pipelining.
Posted: 06/05/2009 01:43:18
by Ken Ivanov (Team)

The issue is definitely related to the pipelining (ASCII mode does not get use of it). Please try to set up TElSimpleSFTPClient in the following way:
1) AutoAdjustTransferBlock to false,
2) PipelineLength to 1,
3) DownloadBlockSize to 32768.
Posted: 06/05/2009 04:40:04
by Frank Munsberg (Standard support level)
Joined: 06/04/2009
Posts: 49

Yes its indeed strange that ASCII mode made the transfer work.

I've tried to disable the SFTP pipelining via .PipelineLength = 1 and .AutoAdjustTransferBlock = false; and things seem to work fine now.
Also ASCII Mode is off now.

For the records: It seems that WS_FTP has problems with the default PipelineLength of 32. I know the docs say it should be 10 but somehow its 32 here. Setting it to 4 did make the transfer work but sometimes there was a little stutter in throughput. Setting it to like 12 made the transfer abort but didn't cause the SSH Server to crash, finally 32 makes the SSH Server crash.
AutoAdjustTransferBlock has to be set to false too.

I just saw your posting Innokentiy. I didn't adjust the BlockSize but it seems that all of you were right saying it was the PipelineLength. Maybe the high default that I had was just way over the top for the FTP Server.

Well, thank you for the help and have a nice weekend!
Posted: 06/05/2009 05:13:08
by Ken Ivanov (Team)

Great, thank you for letting us know.

Would you be so kind to help us improve the components a little? Please let us know the value of ServerSoftwareName property right after TElSimpleSFTPClient.Open() call returns. This will allow us to implement special handling for WS_FTP servers and make the components work with them fine in AutoAdjustTransferBlock mode.

Thank you in advance and have a nice weekend too!
Posted: 06/05/2009 05:37:05
by Frank Munsberg (Standard support level)
Joined: 06/04/2009
Posts: 49

Of course, here goes.

WS_FTP 6.11 identifies as WS_FTP-SSH_6.1.1
and WS_FTP 7.1 as WS_FTP-SSH_7.1

Posted: 06/05/2009 05:43:25
by Ken Ivanov (Team)




Topic viewed 6661 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!