SSH if command output is more than about 5 lines

Question

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

Solution 1

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.

Solution 2

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.

Comments

[Topher Fangio]

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).

[dmckee --- ex-moderator kitten]

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.

[Topher Fangio]

Ah ha ha, Yeah, ServerFault, not StackOverflow...it's a Monday =P

[Steve Townsend]

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 :)

[jarrington]

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

[pQd]

@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?

[jarrington]

@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

[pQd]

@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.

[snazzybouche]

SSH connection was stopping on the first multi-line response every single time, unless I immediately re-opened the SSH afterwards, then it worked fine from then onwards. MTU was 1500. Changed to 1492 and now it works fine.

[djdomi]

SSH if command output is more than about 5 lines was the question, what does this mean to your question?