I am running Windows 7 Professional 64-bit. Two different SSH clients are exhibiting a strange habit of periodically freezing or hanging. I have tried both putty and Van Dyke's SecureCRT SSH clients and in both cases I will get a periodic freeze lasting anywhere from 20 seconds to a few minutes. No key strokes get through during the hang (not Ctrl-C, Ctrl-Z, or anything I have tried).
This happens while connecting to any of a number of servers. Others in my group using non-Windows machines do not seem to be having this problem. So, this is probably not a server-side issue.
I also use RDP to connect to Windows servers without similar freezes, so I don't think it is a networking issue with my machine.
Since this is happening with two different clients it seems like this must be a Windows issue.
Any suggestions?
UPDATE. Paying a little more attention, this only seems to happen when I am using emacs on the remote server. Since the freezing behavior only started when I moved from Windows XP to Windows 7 I attributed it to Windows, but maybe it is due to a more subtle interaction between emacs and Windows 7.
FURTHER UPDATE. My desktop support guy replaced the network cable and the problem seems to have gone away. I cannot explain why I noticed no network issues with my computer other than when working with Emacs through ssh. Perhaps there is something about using Emacs in this fashion that is particularly sensitive to network flakiness.
I use putty under windows and do not have this issue. There is nothing intrinsic to windows that would cause this issue. It could be something like symantec antivirus firewall or another piece of software that is interupting the connection.
The described problem was very annoying too. I tried approach with disabling Large Send Offload and Jumbo Packet as was suggested above (as well as other options in network adapter properties > advanced tab). Unfortunately, the positive result was only "short-time": after adapter reboot, which is necessary to activate chosen adapter options, everything was fine, but then after some time (several minutes) ssh session became laggy/with freezes.
The observed behavior ("smooth" SSH immediately after adapter reboot and laggy after some time) suggested to look at power-saving options. Finally, the problem was solved disabling "Allow the computer to turn off this device to save power" option in Device Manager > Network adapters > adapter properties > Power Management. The problem/solution was successfully reproduced after enabling/disabling this option (the result is seen after some minutes without adapter reboot).
The approach was tested on the following software setups: SSH Secure shell on Windows 7 Professional 64-bit and Putty on Windows 7 Ultimate 64-bit both connected to different Linux servers.
I think that this has something to do with a firewall interrupting the connection. A while ago, I experienced a similar problem but with all kind of client Operating Systems. The ssh connections were interrupted after a while. After debugging, we've found out that the iddle timeout was configured to a very low limit in a firewall between the client machines and that server.
As you are only experiencing this problem in Windows 7, I'm guessing that this might be a software firewall installed on the client machines.
Hope this helps!
Generally speaking, Windows 7/2008 communications over VPN or some WAN, I would recommend setting the network adapter properties > advanced tab > Large Send Offload and Jumbo Packet to disabled.
I had problems with using vi on Putty + Windows 7. As soon as I try to open a file on the remote server using vi, Putty would freeze. I then had to kill Putty and start a new one.
My fix was to disable X11 forwarding on Putty. Hope this helps.
Are you running any software in parallel that intercepts/monitors the keyboard? Some anti-RSI software maybe, or a hotkey/macro manager? (Don't forget hotkey managers for the extra buttons on a multimedia or laptop keyboard.)
Such software may get confused by the control-key/Esc-key combo's that are frequently used by eMacs itself and/or the terminal emulation itself.
I had similar issues in XP and in Win7 caused by our companies anti-RSI software. Affected telnet and ssh, regardless of the software used: Windows own telnet, cygwin ssh client and xterm, putty, SecureCrt, Reflection-X, Attachmate-Extra, eXceed. All had issues. I got rid of the anti-RSI software and the problems disappeared as well. I now use WorkRave which doesn't seem to be affecting the operation of the terminal sessions.