I run Debian Sid on my desktop at home, and Kubuntu on my netbook. I frequently use SSH to control my desktop, to tunnel traffic to my desktop, and for transferring files back and forth (1.75tb in my desktop, 120gb in my netbook, and I have a collection of files totalling about 30gb I use on a regular basis for work that I keep at home for size constraint reasons). For some reason, starting today, all normal SSH activity works, but as soon as I attempt to do file transfer activity, either via mc (which uses fish), or sshfs, the connection instantly dies, leaving a partial file on the receiving end. I can navigate, and all that stuff like normal, but as soon as I start to copy a file, it dies. Nothing on either machine has changed.

What can I do to prevent this from happening?

user sftp to transfer files.
Are you facing same error?

Or if sftp is not working too:

First attempt with SFTP got about 3mb into a file before it stalled. Every time after that I get the following before it drops.
Attempting the second recommendation also gets the packet corrupt line.

Update: It seems to only effect SSH. I'm using FTP to transfer a file that SSH just choked on without any issue. Also, last night I tried transferring with SSH it at my girlfriend's family's house, and had no issues there. SSH transfer in the local network to a machine not outside seems to have issues too

But did FTP transfer the file correctly?

This would suggest corruption on the network, that either isn't detected by TCP checksum because it is occurring at the hosts on an NAT, or is mostly detected TCP checksums.

Wireshark will help in determining what the problem is.

Looks like a bad NIC card on whatever machine is commonly involved for failures. If it's a NIC chip integrated on the mainboard or laptop, this makes it worse. I had this problem happen to me on some servers about a decade ago. They were all the same model, and every such server eventually had the problem. The best I could determine, the deserialization clocking would not hold synchronization for certain data patterns. That was likely a bad voltage regulator feeding the NICs clocking oscillator. Since it was on the mainboard and this model was already old, they were just replaced.

Ok trying one more time (LQ prematurely expired the cookie while I was typing the response)

Using wireshark, I couldn't find any errors for this machine, everything appeared to be fine (I did see some errors in the log, but it was related to another computer). Today I plugged in to a separate network, to work with a test bed server, and attempted to do some work when I was getting the same error. This led me to focus on the computer.

Looking around, I found that quite a few other people were having this issue, with the same model laptop (Lenovo S10e), although much of the issues dated back to 2009 (majority being before I bought mine). A few people mentioned issues up until about a year ago, when things seemed to have dried up, however in various searches I see people complaining about it again after upgrading to Oneiric (which I just did right before the problem started happening). In one bug report for Ubuntu, a work around is shown by using "sudo ethtool -K eth0 rx off tx off" to disable checksumming. This prevents it from killing the connection. I've sent multiple files multiple times each, and used cmp, crc32, and md5sum to go against each of them, and all are identical, with no issues.

To verify if it is hardware or driver issue, I'll boot into windows and try things there (I set this up as dual boot, but never use it, so that's still the factory default). If it bitches there, I'll know it is hardware.

Under Windows, zero errors, absolutely no issues. I was fully expecting an issue, but got nothing.