So I wrote up the following application to help me debug: https://github.com/kitscuzz/n_stress (please note that the CRC32 doesn't work quite how it's meant to, but it has caught corruption pretty consistently)
I have now confirmed that it is not any of my networking equipment, or specific to my machine (which I suppose should have been obvious from the existence of this thread). I have now seen this problem happen on two completely different machines than the three used in the original test, and over a network connection which was in a different part of the state, so that's not the issue. The other machine which appears to have the issue is also using a completely different ethernet controller (though also a gigabit), which would seem to rule out a specific driver issue. I still have not replaced the RAM, but it made it through 72 consecutive passes in RAM test (almost three days) so I'm fairly certain that the ram is good. I think this is explicitly a receive error, as a web server machine running Red Hat 4.1.2 (kernel version 1.6.18) can cause the error in the affected machines, but not others. I have to confirm this by hooking one of them up to a hub or switch which has a windows machine sniffing to see if they both get the corruption. I've attached the lspci -vvv output from all three machines involved. Any help would be immensely appreciated, even if it was just ideas on how to get through the ~6Gb packet dump in wireshark or tcpdump. ** Attachment added: "Here is the output from a debian 32 bit server which has this problem" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/60764/+attachment/1974117/+files/tom_lspci_output.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/60764 Title: Large file transfer gives error: Corrupted MAC on input -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
