3

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.

Thomas Dignan
  • 211
  • 3
  • 13
  • 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 Answers4

5

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.

Olaf
  • 908
  • 5
  • 7
  • 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? – Thomas Dignan May 10 '10 at 21:09
  • Also, I have swapped out the cable for another and still have the same problem – Thomas 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 – Thomas 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
  • why is this being marked as an answer did it actually solve any problem? – tony roth May 11 '10 at 14:06
  • thanks for accepting this as an answer - can you provide some insight into what exactly helped to solve your problem? – Olaf May 11 '10 at 15:54
  • @Olaf, I believe it ended up being something with the nic configuration windows, but it was a long time ago, I do not remember – Thomas Dignan Aug 10 '11 at 08:00
  • I once had a NIC that was corrupting packets only in certain cases with a run of at least 8 binary zero bytes. It would drop one byte, alter a couple others, and shift all the data by a variable amount. But TCP checksum always caught it. Clocking sync was highly suspected. Compression and/or encryption accomplished a short term workaround. Replacing the NIC was the final solution (though a firmware upgrade might have, as well, I didn't have time to load the vendor's favorite OS to do it). – Skaperen Feb 27 '13 at 23:00
1

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

tony roth
  • 3,844
  • 17
  • 14
0

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.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
0

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.

sturgman
  • 101
  • 1
  • 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