> > Also how could wireless link change data inside of a TCP packet ?
> > Then checksum should become wrong and the packet rejected ... ?
>
> 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.
exactly - succesfull completion but invalid data.
> > 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.
I did (I wrote program for it). 16MB are totaly dirrerent
(from offset 14MB aligned on page boundary) and some other
part (10kB) is shifted by 1 byte. That part is not even 512B
aligned. This is list of different parts between 148005111
long files f1 and f2:
from 14557184, cnt 4481067
from 19038287, cnt 11393
at 19038288 (by 1) in f1
at 19038286 (by -1) in f2
from 19049716, cnt 1162
at 19049717 (by 1) in f1
at 19049715 (by -1) in f2
from 19050914, cnt 46210654
from 68514564, cnt 4855808
at 68518659 (by 4095) in f2
"at" block is where the block was found in other file.
devik
