> Received disconnect from 10.0.0.123: 2: Packet corrupt > > I'm using rsync over ssh to transfer some files over my LAN and I'm getting > errors such as the above. The combination of source/target systems is a > common one, I'm transferring the same size files that I often transfer > without > error. The error above has occurred twice in the last hour but never before > on those systems (and I don't recall ever seeing it on any systems before - if > I have seen it before it was a long time ago). > > The target system is running Debian/Unstable and the source is running > Debian/Wheezy with a kernel from Unstable. > > The source is a server with ECC RAM, so RAM errors seem improbable and > CPU > errors don't seem that likely given that it's quality server hardware. The > target is a desktop PC that someone discarded, so if this error is due to > hardware it would almost certainly be related to the desktop PC. > > I'll probably run Memetest86+ on the PC soon, I haven't run it for a long time > and it doesn't do any harm to do such tests occasionally. Any suggestions for > other things I should do? >
If there were memory errors enough to cause the frequency of the problems you are seeing, it would be likely you'd see other effects too. Is virtualisation involved at all? You could try iperf... I'm not completely sure it reports L3 data errors though. Otherwise nc a large gzipped file and see if it arrives intact. Turn off all network acceleration features (TSO/LSO/GSO/CSUM) at both ends and repeat. Also check tcpdump for tcp checksum errors. TCP checksum isn't particularly robust so it's possible you could get a few bits of corruption that just happens to result in the right checksum. Maybe the easiest thing to try though would be to put a network card in the PC and test using that. Not that likely, but very easy to test. Good luck! James _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
