On Mon, Jan 20, 2003 at 03:09:57PM +0100, devik wrote: > > Or imho even more probably, the problem could be the line. I've had a > > couple of these during last 3 years. Namely, is there a serial line > > (possibly wireless) involved? > > Yes it is. There is wireless net inbetween. But interestingly > I have seen no other packet corruption except when communicating > via FTP with concrete W2k user. > He can FTP with others as I can too but can't between themselves. > > Also how could wireless link change data inside of a TCP packet ? > Then checksum should become wrong and the packet rejected ... ? Yes, they should. What I had in mind was a data-dependent bug on a 2 Mbps wireless link that caused packets having alternate zero and one patterns in it (0x5555 or 0xaaaa) to be dropped by the link and never seen by the receiver. Now, I'm not sure what the exact symptoms are of what you are solving. If your problem is that the TCP transmission completes successfully (i.e. everything's OK as far as TCP is concerned) but the data that came out of the pipe is different that the data that had been sent, that should be a different problem. > I changed proftpd to compute and log MD5 of each chunk of data > going out of read() syscall so I will be able to compare them > to file on HDD (catching errors in FS, IDE (DMA) or HDD). > Also in the same time I'll save tcpdump's raw packets to be able > to compare stored data with packet contents (with 100MB ftp file > it will be a lot of fun :-( ) Can you produce a "binary diff" of sent and received file to see how exactly they differ? Are the two files completely different? Or do they differ just in a couple of places? Is something missing? Is something changed? If so, how? That's how I managed to isolate some difficult data-dependent bugs, it might be useful here, too. pvl
