Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am consistently experiencing corrupt downloads over TCP/IP and Ethernet on a small LAN, the downloads are coming from different sources on the Internet. WAN is comcast cable.. NIC is brand new.

My theory is that this is being caused by a bad ethernet cable.

What are the possible causes? I am in the process of testing the ethernet theory now.

share|improve this question
2  
I would be tempted to boot off a linux livecd and attempted a download so you can rule out issues with your client OS. –  Zoredache May 10 '10 at 20:31

4 Answers 4

up vote 5 down vote accepted

The cable should be ruled out by the network protocol - I'm not that deep into tcp, but would expect that tcp handles cable errors through some kind of checksums, so that corrupt packets are detected.

Disintermediate the cabling theory and (almost) everybody on the outside: Test downloads through https. This way you can be sure that the problem is either the server (outside of your control, unlikely) or your local setup (likely) should this reproduce the error. Cabling and corrupting data on the WAN side are completely ruled out once you go encrypted.

See if only certain types of downloads are corrupted: E.g. executables, text files etc. Detect in what way they have been changed (MD5SUM, diff tool)

If the problem persists try to temporary disable your virus scanner: This might cause problems. Also: Try to detect (with a scanner from a boot-cd) if you're infected by some malware that immediately tries to infect your new downloads, thereby corrupting them (you can't do that from within a running system).

If your question regards ftp, make sure you download BINARY, not ASCII.

If this doesn't help, report back.

share|improve this answer
    
Since this is a brand new computer with a brand new install of windows 7, I doubt it has a virus, so that is ruled out. I have tested HTTP downloads with MD5 and CRC from multiple sources to find a corrupt file every time (usually >50mb files). It's not a certain type of file, ISO, exe, zip, all have the same problem. When using bittorrent there was no corruption. I think that's because bittorrent verifies the chunks with sha1 or something. Are you sure that TCP's checksum covers the payload and not just the TCP header part of the packet? Why else would there be MD5s on many download sites? –  Tom Dignan May 10 '10 at 21:09
    
Also, I have swapped out the cable for another and still have the same problem –  Tom Dignan May 10 '10 at 21:09
    
I suppose the cable I replaced it with could also be bad or one on the other side of the router –  Tom Dignan May 10 '10 at 21:14
    
MD5 is there for you to be sure that you've got the correct file even when downloaded from a mirror site. Make sure to always get the MD5 from the original site, not from the mirror. Have you tried https (or ssh or anything encrypted) yet? If this is also corrupted, everything in the network can be ruled out. If it is not, there might be some eavesdropping component on your way - e.g. a proxy running virus checks or something else. Are all your problems from varying sources or all from the same source? Can you post links to check? –  Olaf May 11 '10 at 12:05
    
and: Don't rule out malware just because you doubt that it's there. This can be quicker than you think. Check it, double check! Remember: you're observing some strange behaviour after all. –  Olaf May 11 '10 at 12:08

if you have a caching service/server somewhere that could be the problem also

share|improve this answer

Try downloading with a different protocol to see if it makes a difference. I'm assuming these are HTTP downloads so try downloading something via FTP.

share|improve this answer

I know this is an old question but my solution was to revert the driver of my nic. Windows 7 had updated it and that is when my problems started. Once I reverted to an older version no more download corruption was observed.

share|improve this answer
    
That would strongly suggest that the TCP/IP stack was not performing the CRC checks on TCP that it should have, or the rare chance of corruption colliding the same CRC for however much corruption is seen. –  Skaperen Feb 27 '13 at 22:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.