FTP file corruption from 32 bit Windows clients

SUSE Linux Enterprise Server SLES Networking
1

We have a very odd issue we are trying to solve. We have several FTP servers that serve up FTP, Samba and NFS. Some run SLES 10 SP1, the later ones run SLES 11 SP1. The 10GbE NICs installed in the machines are identical. We need to move FTP clients to the servers running SLES 11 SP1.

During this we noticed that if you MD5 a file that has been transferred via FTP to a Windows 32 bit client from a SLES 11 SP1 server it does not come back as expected. The file has become corrupted. The same process from a SLES 10 SP1 server yields the correct MD5.

If you do the same transfer using Samba the MD5s are correct from both servers. We have tried building pure-ftp from source and running the same versions on both SLES 10 and SLES 11. SLES 11 still has the corruption issue.

To add confusion, performing an FTP transfer from a linux client or Windows 64 bit client, the FTP transfers are fine from both the SLES 10 or SLES 11 servers…

We have tried upgrading the network drivers on the windows 32 bit clients and the Linux servers, but made no difference. Also tried disabling the TCP offload checksum on the windows 32 bit clients - again, no change.

Any ideas would be much appreciated!

2

Comments from OpenSuse forums:

On 09/11/2013 07:16 AM, dom era wrote:

We have a very odd issue we are trying to solve. We have several FTP
servers that serve up FTP, Samba and NFS. Some run SLES 10 SP1, the
later ones run SLES 11 SP1. The 10GbE NICs installed in the machines are
identical. We need to move FTP clients to the servers running SLES 11
SP1.

Good initial description.

During this we noticed that if you MD5 a file that has been transferred
via FTP to a Windows 32 bit client from a SLES 11 SP1 server it does not
come back as expected. The file has become corrupted. The same process
from a SLES 10 SP1 server yields the correct MD5.

Stop using windows? I (mostly) kid.

If you do the same transfer using Samba the MD5s are correct from both
servers. We have tried building pure-ftp from source and running the
same versions on both SLES 10 and SLES 11. SLES 11 still has the
corruption issue.

Different protocol, so the difference appears to be related to FTP at this
point.

To add confusion, performing an FTP transfer from a linux client or
Windows 64 bit client, the FTP transfers are fine from both the SLES 10
or SLES 11 servers…

And since FTP is both a protocol as well as a command, apparently the
implementation differs between proper OS’s and deficient alternatives.

We have tried upgrading the network drivers on the windows 32 bit
clients and the Linux servers, but made no difference. Also tried
disabling the TCP offload checksum on the windows 32 bit clients -
again, no change.

Um… wow. Network drivers and Linux (which works) itself? Disabling TCP
checksum offloading? Those are some interesting steps, but why do them
when other layer seven protocols (SMB via Samba) work?

The problem is almost certainly that you’re using FTP (on windows) in
ASCII (vs. BINARY) mode. If you are using the command line just type
‘binary’ once you have authenticated to the FTP server. Linux does this
by default because it’s not stupid and ASCII mode is stupid.

Good luck.

3

Sorry I should have mentioned that we confirmed that transfers were all being completed in binary mode, that was our first conclusion, but we shall recheck.

Also agree that driver updates and disabling TCP offloading was unlikely to change things when other protocols function correctly, but these seemed like sensible things to try.

We also tried building a server with RHEL 6.4. This showed the same issue as SLES 11.

Something in common between the 2 is they are both on kernel version 2.6.32.

SLES 10 SP1 is on kernel version 2.6.16

4

Also as posted in the openSUSE forum, but abandon that if you’re done there:
[color=blue]

ascii vs. binary[/color]

Good to know. Yes, this is usually the issue.

Other possible issues could arise around file size. For example, if the
‘ftp’ client on windows does not handle large files, for some varying
definition of “large”, then that would explain things. To rule this
in/out test with something else, like Firefox as the FTP client or some
other tool like FileZilla.
[color=blue]

Also agree that driver updates and disabling TCP offloading was unlikely
to change things when other protocols function correctly, but these
seemed like sensible things to try.[/color]

Fair enough. I’m glad they didn’t pan out as I would have been profoundly
confused had those been related to any significant degree. For now I’d
try ruling out the client utility by using other clients. Obviously your
filesystem can handle the file (windows filesystems often have problems
with larger files depending on the one used, such as fat32) which lead to
your exact symptom, and there have been issues for years with “larger”
files not working when downloaded via tools like microsoft’s internet
explorer… yet another reason to use an alternative browser or tool.

Good luck.

5

[QUOTE=ab;16207]Also as posted in the openSUSE forum, but abandon that if you’re done there:
[color=blue]

ascii vs. binary[/color]

Good to know. Yes, this is usually the issue.

Other possible issues could arise around file size. For example, if the
‘ftp’ client on windows does not handle large files, for some varying
definition of “large”, then that would explain things. To rule this
in/out test with something else, like Firefox as the FTP client or some
other tool like FileZilla.
[color=blue]

Also agree that driver updates and disabling TCP offloading was unlikely
to change things when other protocols function correctly, but these
seemed like sensible things to try.[/color]

Fair enough. I’m glad they didn’t pan out as I would have been profoundly
confused had those been related to any significant degree. For now I’d
try ruling out the client utility by using other clients. Obviously your
filesystem can handle the file (windows filesystems often have problems
with larger files depending on the one used, such as fat32) which lead to
your exact symptom, and there have been issues for years with “larger”
files not working when downloaded via tools like microsoft’s internet
explorer… yet another reason to use an alternative browser or tool.

Good luck.[/QUOTE]

We have tried several different FTP clients including FileZilla. However, I do not see this as being an issue. The client downloads the same files successfully from a server running SLES10, but the corruption happens when downloading from SLES11. These are both serving up the same file system, via the same protocol (FTP). The only difference in config is the SLES version. This makes me think that there are some kernel changes that may be having an effect on FTP transfers.

6

dom era wrote:
[color=blue]

The only difference in config
is the SLES version. This makes me think that there are some kernel
changes that may be having an effect on FTP transfers.[/color]

As you point out, this only became an issue when using SLES11-SP1 so it
is reasonable to assume /something/ in SLES has changed. Have you
considered installing SLES11-SP3 which is the current version to see if
it resolves your issue?

The correct way to resolve an issue like this is to diagnose the
problem first, then attempt to find a solution. I realise you have been
trying to do this and it is not always easy. :frowning:

Does this happen with all file transfers? If so, can you run a packet
trace while retrieving a small file from each server and compare the
results to see what is different?

Even if you can pinpoint the problem, the only solution may be to
upgrade to the current release so I would think that should be your
first course of action.

–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

7

Many thanks for the reply. We are tried to this version due to support from another vendor only being on this level of OS, so an upgrade to 11 SP 3 is not an option. The other odd thing is that Cent OS 6.4 displays the same issue, and is more or less on the same kernel version.

It appears I am the first to be seeing this issue via FTP, so we shall do some packet traces and more comparisons.

8

Hi
What about opening a command window and using the command line version
of ftp on the windows clients, does that work?

Maybe you should switch to ssh/sftp eg winscp (it does ftp as well
AFAIK)?

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 12.3 (x86_64) GNOME 3.8.4 Kernel 3.7.10-1.16-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

9

[QUOTE=malcolmlewis;16229]Hi
What about opening a command window and using the command line version
of ftp on the windows clients, does that work?

Maybe you should switch to ssh/sftp eg winscp (it does ftp as well
AFAIK)?[/QUOTE]

Command line has same issue. MD5s come back incorrectly. It does not matter which client is used. Pulling data via FTP from the SLES11 always results in incorrect checksums. Pulling data from the SLES10 server via FTP always provides the correct checksums.

10

dom era wrote:
[color=blue]

Pulling data via FTP from the SLES11 always
results in incorrect checksums.[/color]

If you go here:
http://support.novell.com/lifecycle/

and enter “SUSE Linux Enterprise Server 11”

You’ll see that SUSE general support ended on 31 August 2012 so you
won’t likely get any new patches from SUSE.

Perhaps you can get your “other” vendor to fix this issue in
SLES11-SP1? :slight_smile: If they won’t, you don’t have a lot of options.

If you can verify your FTP downloads are working with SP2 or SP3 and
can find the specific bug that was resolved, you /may/ be able install
the fix on SP1.

If you can verify the issue still exists on SP3, I can try and have a
bug opened to have it corrected.

Other than that, I’m afraid I’m out of ideas.

–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…