Hi,
The other night, my friend was sending me a video over the internet.
We tried http, ftp, and other protocols, using different download
applications. It seemed to be corrupt, the same way, everytime. It
wouldn't work, and had a different md5sum than the "good" version on my
friend's computer. Eventually we got it working.
The same issue came up again today. I uploaded my Java project on my
professor's server and it gives me an error. However, if I load the
html file with the Java applet in my web browser from this hard disk
(instead of from the prof's), it works.
I am wondering if there is some sort of corruption going on here. I am
using Red Hat's 2.4.9-21 kernel.
Thanks
Kevin Breit
> We tried http, ftp, and other protocols, using different download
> applications. It seemed to be corrupt, the same way, everytime. It
> wouldn't work, and had a different md5sum than the "good" version on my
> friend's computer. Eventually we got it working.
> The same issue came up again today. I uploaded my Java project on my
> professor's server and it gives me an error. However, if I load the
> html file with the Java applet in my web browser from this hard disk
> (instead of from the prof's), it works.
> I am wondering if there is some sort of corruption going on here. I am
> using Red Hat's 2.4.9-21 kernel.
At the physical layer ethernet has hardware checksumming, at the IP/TCP layer
there is also checksum protection. That means that its almost certainly either
- Problem hardware/driver
- Some kind of broken transparent proxy server between the two boxes
What you really want to try is to upload the same files via different
machines to find out which end is the problem, or if it is perhaps the
link between them - eg does it go away only if both boxes are on the same
LAN.
Alan
On 28 Jan 2002, Kevin Breit wrote:
> Hi,
> The other night, my friend was sending me a video over the internet.
> We tried http, ftp, and other protocols, using different download
> applications. It seemed to be corrupt, the same way, everytime. It
> wouldn't work, and had a different md5sum than the "good" version on my
> friend's computer. Eventually we got it working.
> The same issue came up again today. I uploaded my Java project on my
> professor's server and it gives me an error. However, if I load the
> html file with the Java applet in my web browser from this hard disk
> (instead of from the prof's), it works.
> I am wondering if there is some sort of corruption going on here. I am
> using Red Hat's 2.4.9-21 kernel.
>
> Thanks
>
> Kevin Breit
>
Every TCP/IP data packet is check-summed. Every Ethernet packet has
a CRC. If you have data corruption it is caused either by a memory
error or, most likely, you did not set the ftp data-transfer mode
to binary `set bin` when you have the 'ftp>' prompt.
Also, text-files (Java Script) on DOS-based stuff (like windows) use
both a '\r' and a '\n' at the end of each line. Unix/Linux uses '\n'
only. I am pretty sure this is not a kernel issue.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
> The other night, my friend was sending me a video over the internet.
> We tried http, ftp, and other protocols, using different download
> applications. It seemed to be corrupt, the same way, everytime. It
> wouldn't work, and had a different md5sum than the "good" version on my
> friend's computer. Eventually we got it working.
>[...]
Two things are likely:
1. a firewall mangles your TCP streams
2. something is wrong between the driver and the NIC.
-- Pete
Kevin Breit wrote:
>
> Hi,
> The other night, my friend was sending me a video over the internet.
> We tried http, ftp, and other protocols, using different download
> applications. It seemed to be corrupt, the same way, everytime. It
> wouldn't work, and had a different md5sum than the "good" version on my
> friend's computer. Eventually we got it working.
> The same issue came up again today. I uploaded my Java project on my
> professor's server and it gives me an error. However, if I load the
> html file with the Java applet in my web browser from this hard disk
> (instead of from the prof's), it works.
> I am wondering if there is some sort of corruption going on here. I am
> using Red Hat's 2.4.9-21 kernel.
>
Generally, IP checksumming should catch this.
However, a number of ethernet cards do IP checksumming in
hardware, so the kernel doesn't bother doing the checksum
in software.
So if you are experiencing data corruption on the path
between the NIC's FIFO memory, the PCI bus and main memory,
it will not be detected. This is somewhat of a flaw in the
whole idea of checksum offload, IMO...
What ethernet card are you using?
-
On Mon, 2002-01-28 at 13:58, Richard B. Johnson wrote:
> Every TCP/IP data packet is check-summed. Every Ethernet packet has
> a CRC. If you have data corruption it is caused either by a memory
> error or, most likely, you did not set the ftp data-transfer mode
> to binary `set bin` when you have the 'ftp>' prompt.
I believed that I was uploading in bin mode anyways. As when I opened
gftp, it said I was uising Binary mode.
> Also, text-files (Java Script) on DOS-based stuff (like windows) use
> both a '\r' and a '\n' at the end of each line. Unix/Linux uses '\n'
> only. I am pretty sure this is not a kernel issue.
My professor's server is a Mac box. I doubt this is an issue anyways.
Thanks
Kevin Breit
On Mon, 2002-01-28 at 13:57, Alan Cox wrote:
> At the physical layer ethernet has hardware checksumming, at the IP/TCP layer
> there is also checksum protection. That means that its almost certainly either
>
> - Problem hardware/driver
The hardware on this box _is_ quite poor. I do have a LOT of problems
with Linux on here, so this could be it.
> - Some kind of broken transparent proxy server between the two boxes
>
> What you really want to try is to upload the same files via different
> machines to find out which end is the problem, or if it is perhaps the
> link between them - eg does it go away only if both boxes are on the same
> LAN.
I'll try this from my desktop box tomorrow.
Thanks a lot
Kevin Breit
On Mon, 2002-01-28 at 13:56, Pete Zaitcev wrote:
> 2. something is wrong between the driver and the NIC.
As I said in a previous email, I think this is it. Because a couple
minutes after I sent my email, the upload worked perfectly.
Kevin Breit
On Mon, 2002-01-28 at 14:01, Andrew Morton wrote:
> However, a number of ethernet cards do IP checksumming in
> hardware, so the kernel doesn't bother doing the checksum
> in software.
Interesting
> What ethernet card are you using?
I am using a built in (I think it's on the mobo actually) Intel
EtherExpress 10/100 Pro:
eepro100 17680 1
Thanks for the help
Kevin Breit
Kevin Breit wrote:
>
> On Mon, 2002-01-28 at 14:01, Andrew Morton wrote:
> > However, a number of ethernet cards do IP checksumming in
> > hardware, so the kernel doesn't bother doing the checksum
> > in software.
> Interesting
>
> > What ethernet card are you using?
> I am using a built in (I think it's on the mobo actually) Intel
> EtherExpress 10/100 Pro:
>
> eepro100 17680 1
>
Oh well, there goes that theory. eepro100.c does software
checksumming.
-
Pete Zaitcev wrote:
> > The other night, my friend was sending me a video over the internet.
> > We tried http, ftp, and other protocols, using different download
> > applications. It seemed to be corrupt, the same way, everytime. It
> > wouldn't work, and had a different md5sum than the "good" version on my
> > friend's computer. Eventually we got it working.
> >[...]
>
> Two things are likely:
>
> 1. a firewall mangles your TCP streams
>
> 2. something is wrong between the driver and the NIC.
3. An error source in the transmission path exchanging 0x00 0x00
against 0xff 0xff sequences will go undetected by TCP CRC.
"diff -u" onto "od"-output will help understanding your error pattern.