Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
SDN 101: An Introduction to Software Defined Networking
Discover the advantages of SDN.
SDN has quickly become one of the hottest trends in IT. But not all SDN solutions offer real software-defined functionality. As more enterprises consider SDN, they want to know, “What is SDN? And what are the real benefits?” If you're ready to explore the advantages of SDN, and want to know how it should be implemented within your enterprise, start by reading our introductory white paper.
Click Here to receive this Complete Guide absolutely free.
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.
First attempt with SFTP got about 3mb into a file before it stalled. Every time after that I get the following before it drops.
Received disconnect from <IPADDRESSGOESHERE>: 2: Packet corrupt
Couldn't read packet: Connection reset by peer
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
Received disconnect from 10.1.1.156: 2: Corrupted MAC on input.
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.