On Sun, 2010-01-10 at 05:06 +0100, nurbs...@gmx.de wrote: > Well, I don't think it's problem with your filesystem, Benoit, and > further I still think it's problem with the driver. If I use > ndiswrapper-module with the windows drivers I don't have this problem. I > still get disconnected after some time but I get correct packets, > meaning the md5sum is correct even though I have to reconnect to the > access point and resume the download.
If the driver is responsible for that, then it must be something really bad, like memory corruption. Simple accepting wrong data from the AP won't do it. > And what do you mean by using TCP to download the files? To download > files you always have to use a protocol like http, ftp, etc. Thats one > layer below TCP or am I missunderstanding something? Yes, I meant a TCP based protocol. TCP should have enough protection against data corruption if it works correctly, that is, there is no memory or disk corruption. Some protocols, such as tftp, are UDP based and don't have such protection, even though checksums are used on other layers. > And my other question was how to debug the driver and traffic to find > out whats going wrong. Any ideas? I would try to enable most kernel debug options to find possible corruption. Also, I would compare corrupt files with the correct ones by cmp. Contiguous groups of corrupted bytes would indicate corruption by the kernel code. Corruption in random bits would indicate a hardware issue. -- Regards, Pavel Roskin _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
