up vote 0 down vote favorite
share [g+] share [fb]

I've been advised to ask this question here: I'm baffled by the following issue I'm currently experiencing.
I have a Debian 5.0 Linux server connected via an ethernet cable to my DSL router. My laptop is running Windows 7 and is connected wirelessly (802.11b/g) to the same DSL router. If I SSH into the server using Putty and attempt to execute a command which results in multiple lines of output my SSH session freezes. Ex.

ls -al /             // Freezes
ls -al / > ~/boo.txt // OK
vi ~/boo.txt         // OK
top                  // Freezes

All the above commands work if I execute them directly on the server or if I change my laptop's connection to a wired connection. What gives? This problem is really baffling me! Thanks

link|improve this question
Might want to ask this on StackOverflow, but it sounds like it might be a problem with special characters (color perhaps) as vi doesn't do any coloring (unless it's actually vim). – Topher Fangio Dec 21 '09 at 21:47
He did ask it on StackOverflow, but would probably be better moving it to ServerFault...and I'm with Aidan: my first suspect was the network MTU. – dmckee Dec 21 '09 at 21:52
Ah ha ha, Yeah, ServerFault, not StackOverflow...it's a Monday =P – Topher Fangio Dec 21 '09 at 21:59
feedback

3 Answers

up vote 3 down vote accepted

sounds like a wired MTU issue. slightly...

is it possible that you have jumboframes enabled? probably not. anyway - try setting lower mtu on the debian and see if it helps.

link|improve this answer
Seconded; this sounds like a MTU problem. I'd suggest trying larger and larger packets (easily done using ping) until you get errors/dropped packets. Or just check MTU settings everywhere :) – MikeyB Dec 22 '09 at 4:37
Thanks people! Lower MTU on laptop's done the trick. Does MTU apply to sender/receiver/both? I could ping server from laptop with larger data size. The reverse wasn't true. Linux server: ~# ping -S 5000 athlon64-laptop.lan PING athlon64-laptop.lan 56(84) bytes of data 64 bytes from x.x.x.x: icmp_seq=1 ttl=128 time=2.71 ms On windows laptop >ping -l 2048 athlon64x2-server.lan Pinging athlon64x2-server.lan with 2048 bytes of data: Request timed out. >ping -l 1048 athlon64x2-server.lan Pinging athlon64x2-server.lan with 1048 bytes of data: Reply from x.x.x.x: bytes=1048 time=3ms TTL=64 – user91234 Dec 22 '09 at 19:34
@leftbrainlogic - problems with mtu indcate that there is something fishy in your network. maybe accesspoint do not pass biggest allowed [ 1500B ] frames for fast ethernet? did you configured manually the server to use jumboframes? – pQd Dec 22 '09 at 19:39
@pQd - Nope, the server is just running a vanilla install of Debian 5.0. I accepted all defaults except for disk partitioning and hostname Output from ifconfig -a is here: pastebin.com/f78fcbf3d – user91234 Dec 22 '09 at 20:27
@leftbrainlogic - ok ; try lowering mtu as described in my link. your 1500B is helahtly standard length, i think this indicates some problem with either switch, access point or wifi network card. – pQd Dec 22 '09 at 20:31
feedback
up vote 2 down vote

There's probably a problem with the MTU of your network connection - when the Linux server attempts to send too many bytes of data in a single network packet, probably the router is refusing to forward it to the windows box, because it thinks the packet size is too large to send over the wireless network. You should be able to reduce the MTU for the Ethernet interface on the linux box, and this would probably solve your problem.

To diagnose, try ping -s <packetsize> <windows-ip> from the linux box to the IP of your windows machine, and ping <linux-ip> <packetsize> from the windows box to linux, with different values for the packetsize parameter, and see if the maximum size is different in either direction.

Also: man ping on linux will be helpful for understanding what's going on.

link|improve this answer
feedback
up vote 0 down vote

The first thing to do is to enable debug mode, both on the client and server.

PuTTY has built-in debugging that is available under Session -> Logging. Note that you need to load the session you are going to use prior to setting the Logging settings. Logging settings are part of a session's configuration.

On the server, you could leave the LogLevel to INFO (in /etc/ssh/sshd_config) and change it to DEBUG only if you can't see anything related to your problem. Remember to log out and restart the ssh server to apply the changes (/etc/init.d/ssh restart). If DEBUG gives no useful information, try DEBUG3, as per man sshd_config.

Please update your question with your findings!

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard