When executing commands via SSH from a Windows 7 laptop (wireless 802.11b/g) to a Debian 5.0 server, the session freezes when command output exceeds approximately 5 lines. However, the same commands work perfectly when:

• Executed directly on the server
• Using a wired connection from the laptop
• Redirecting output to a file (e.g., ls -al / > output.txt)

ls -al /          # Freezes
top               # Freezes
df -h             # Freezes
ps aux            # Freezes

ls -al / > output.txt  # Works
vi output.txt          # Works
cat /proc/meminfo      # Works (short output)

The issue stems from MTU (Maximum Transmission Unit) mismatches in the wireless network path. Wireless connections often have lower MTU values than wired networks, and SSH is particularly sensitive to packet fragmentation.

Solution 1: Adjust MTU on client machine

# Windows (run as Administrator):
netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=persistent

# Linux:
sudo ifconfig wlan0 mtu 1400

Solution 2: Use SSH compression

ssh -C user@server

Solution 3: Limit output pagination

ls -al / | head -n 20  # Show first 20 lines only

Add to your SSH config file (~/.ssh/config):

Host *
    Compression yes
    ServerAliveInterval 60
    TCPKeepAlive yes

To verify packet fragmentation:

ping -f -l 1472 server_ip  # Windows
ping -M do -s 1472 server_ip  # Linux

---

Many developers encounter this puzzling scenario: SSH sessions work perfectly over wired connections but freeze when running commands with multi-line output over WiFi. Let's dissect this common but poorly documented issue.

Here's what typically triggers the freeze:

# These will freeze over wireless SSH:
ls -la /
dmesg
systemctl status
top

# These work normally:
ls -la / > output.txt
cat /proc/cpuinfo | head -5
vim somefile.txt

The issue stems from MTU (Maximum Transmission Unit) mismatches in the network path. Wireless networks often use smaller MTU sizes than wired networks (typically 1500 bytes). When large output exceeds the MTU size without proper fragmentation:

• Packets get dropped silently
• TCP window scaling fails
• SSH session appears frozen

1. Adjust MTU Settings

On the client machine (Windows in this case):

netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=persistent

2. Force SSH Packet Fragmentation

Add these to your SSH client config (~/.ssh/config):

Host *
  IPQoS throughput
  ServerAliveInterval 60
  TCPKeepAlive yes

3. Use Output Pagers

Force pagination for all commands:

# In .bashrc
export PAGER="less -SFX"
alias ls="ls --color=always | $PAGER"

For situations where you can't modify network settings:

# Redirect output to files
command > output.txt
less output.txt

# Use screen/tmux on server
screen -S session
# Run commands normally

To verify the MTU theory:

ping -f -l 1472 example.com  # Find max unfragmented size
tracepath example.com       # Show MTU at each hop
netstat -i                  # Check interface MTUs

For enterprise environments:

• Configure routers to handle MSS clamping
• Implement proper QoS for SSH traffic
• Consider VPN tunneling for all remote access

Remember that wireless conditions may vary day-to-day. What works today might need adjustment tomorrow as network infrastructure changes.