> Normally, TCP checksum is not supposed to be changed (or even read) > at all during transfer (see rfc793 or TCP/IP Illustrated Vol.1). > > If NAT is in use then it needs to be accounted for, of course, because > TCP chksum involves a pseudoheader which contains both source and > destination addresses - but this is not the case, as you say. I thought so. > 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 ... ? 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 :-( ) thanks for all who replied, if someone has another ideas I'm curious :) devik
