Transfer Integrity Problem

Greetings,

My id is 400000197. I have been having some issues transferring files since upgrading to the latest version. From looking at some of the other posts, it appears as though others may be experiencing similar problems. Here are some of the threads:

https://www.smartftp.com/forums/viewtopic.php?t=6135
https://www.smartftp.com/forums/viewtopic.ph ... hlight=zip

Things worked fine with previous versions. Now typically when I attempt to upload ZIP files to an ftp site they get corrupted. Settings have not changed and I am connecting using a Favorites entry that I created a while ago.

SmartFTP is configured for non-passive connections because of our service provider.

Any help would be appreciated.

Regards,

Britain Crooker

ps: Here is my system info:

+- System -----------------------------

Microsoft Windows XP Professional
Service Pack 1 (Build 2600)

CPU Speed : 799 MHz
Total Memory : 785392 KB
Free Memory : 353396 KB

+- SmartFTP ---------------------------

Version : 1.0.978.5
Time Stamp : 2003-08-07 22:05:04

+- Application DLL --------------------

controls.dll : 1.6.978.5
ftpapi.dll : 2.0.978.5
language.dll : 1.0.978.5
reseng.dll : 1.3.978.5
smarthook.dll : 1.0.2.1

+- System DLL -------------------------

shell32.dll : 6.00.2800.1233 (xpsp2.030604-1804)
shlwapi.dll : 6.00.2800.1226
comctl32.dll : 6.0 (xpsp1.020828-1920)
riched20.dll : 5.30.23.1211
schannel.dll : 5.1.2600.1106 (xpsp1.020828-1920)

+- Internet Explorer ------------------

Version : 6.0.2800.1106

+- Winsock ----------------------------

Winsock : 2.2

Please update to the latest build:
https://www.smartftp.com/download

But I'm pretty sure the problem is not with SmartFTP. As mentioned in the other posts, the problem was most of the time with users uploading binary files in ascii mode or with buggy server software. Furthermore data corruption can also be caused between SmartFTP and the server software.

Try to upload the zip files to a different server and check if you have the same problem.

Regards,
-Mat

Is the version you referenced a beta? I am running build 978 which I thought was the latest.

One thing that I didn't mention was that if I use the command line FTP in Windows XP it always works fine. Also, SmartFTP shouldn't be using ascii in this case (which I don't think it is) because the ZIP extension should trigger it to use binary since I have the type set to 'Auto.'

Also, I have been transferring files to this specific ftp site for a couple of years now and things only started not working with the latest version.

Regards,

Britain

I double-checked the settings and everything is binary. Here is a log of a session where the upload was corrupted:

200 PORT command successful
Opening data connection IP: 192.168.1.101 PORT: 1527.
STOR DemoPureEdit.30913a2.zip
150 Opening BINARY mode data connection for DemoPureEdit.30913a2.zip
183018 bytes sent successfully. (11.17 KB/s) (00:00:16).
226 Transfer complete.
TYPE A
200 Type set to A
PORT 192,168,1,101,5,248
200 PORT command successful
Opening data connection IP: 192.168.1.101 PORT: 1528.
LIST -aL
150 Opening ASCII mode data connection for file list
1056 bytes received successfully. (1.03 KB/s) (00:00:01).
226 Transfer complete.
TYPE I
200 Type set to I
PORT 192,168,1,101,5,250
500 ORT not understood
PORT 192,168,1,101,5,251
200 PORT command successful
Opening data connection IP: 192.168.1.101 PORT: 1531.
RETR DemoPureEdit.30913a2.zip
150 Opening BINARY mode data connection for DemoPureEdit.30913a2.zip (183018 bytes)
183018 bytes received successfully. (29.79 KB/s) (00:00:06).
226 Transfer complete.

Log includes both upload and then immediate download of the file.

Britain

Sorry, I mistyped earlier. I meant to say everything was set to auto.

Just tried with new build, same behavior.

Is there some way of downloading previous builds? I cannot seem to find the setups from previous ones. I am sure the build prior to 978 worked fine. I would like to test it again.

Britain

You can always grab an older build from:
https://www.smartftp.com/Products/SmartFTP/
In this time frame, the (976) is available.

To downgrade, extract and overwrite all file(s) into your SmartFTP
installation folder "C:Program FilesSmartFTP", when prompted to.

By the way, please before opening SmartFTP, make sure that
you move all your *.dat files, to a temp. location.

The downgraded build will recreate the default *.dat files, in the
"Data File path" location you have set, via the general settings.

Once you have tested that the problem does, or does not exist
in the older build, then upgrade back to the newer build, and you
may overwrite the files again, to the ones you moved earlier.

The reason this is done this way. I don't want your *.dat files to
get corrupted in any way, because downgrading to an older build,
can cause such problems, since the format of the *.dat files were
changed from 976 to 978. Please let us know how it goes for you.

The previous build 976 seems to work fine. I was able to transfer the file 5 times w/o problem. Before at least 2 out of 3 uploads would result in the problem.

Britain

Very strange that it's working on the 976 build.

MB will need to take a look at the code it seems.

Thanks for verifying it on the 976 build.

Hello,

A "Transfer Type" bug was fixed today.

Please grab the latest dev. build for the fix.
https://www.smartftp.com/download

This problem seems to be back for me with the latest version.

Your problem is very likely not related to SmartFTP.

Without a log and a detailed problem description it's pretty hard to figure out whats going on.

I didn't post any additional info because the problem is identical to last time. The problem seems to be related to the transfer type again. Each time I transfer a ZIP file it gets corrupted on the other end, evident via a CRC error. Downgrading to 976 corrects the problem without fail.

I had downloaded the 979 dev build based on this thread which seemed to resolve the problem. So perhaps between the 979 dev build and its release the problem was reinstated in some fashion.

The one slight oddity with my setup is that I use Active vs. Passive mode for port assignment. This is required because of my ISP.

Regards,

Britain Crooker
FifthOrder Technologies

It looks like some kind of memory corruption either caused by a hardware failure (RAM) or a software on your computer. We can exclude buffer overflows and/or heap corruption in this part of the code inside SmartFTP.

To test your physical memory use memtest86:
http://www.memtest86.com/

Given that transfers via build 976 work fine, the Windows XP command-line FTP works fine and the build 979 doesn't work I find it a bit hard to believe that the problem is not within the 979 build of SmartFTP.

Is there any way to turn on some additional debugging for file transfers to verify that the upload was successful?

Regards,

Britain Crooker
FifthOrder Technologies

Hello ...

We try to help you solve a problem which is very likely not caused by SmartFTP, please consider the suggestions we give you.
Identify what applications are installed on your computer and which may interfer with SmartFTP and / or the winsock layer. e.g. personal firewalls, AV software. McAfee's LSP layer is known to cause a lot of problems.
Then temporary uninstall any software which may interfer with the winsock layer. At last don't forget to check your physical memory with memtest86.

We can analyze a sample (original and corrupt file) for possible heap corruption. Please use QuickSFV to create a .sfv file with CRC sums of both files. You can email it to bugreport attttt smartftp.com

Thank you.

Regards,

I have emailed the files as requested.

Most of the software on my laptop is fairly typical. Norton Antivirus 2003, ZoneAlarm 4.5x Pro, Windows XP with all patches. Also using a Linksys 802.11g PC card.

As far as the memory test - wouldn't this affect any FTP app, especially older versions of SmartFTP?

Thanks,

Britain Crooker
FifthOrder Technologies

From "bcrooker" over email:

"I believe I found the problem - after uninstalling a number of apps on my computer with no affect I decided to try updating the firmware on my Linksys Router (a BEFSR41) to the latest rev, 1.45.7, and now the transfers work fine. Perhaps the fix is related to this line item in the Linksys Firmware release notes:

Fixed fragmented packets arriving out of order. "