SSH hangs frequently over wireless connection
 

Can anyone suggest how to troubleshoot SSH sessions frequently hanging(but always recovering) over a wireless network? There is no problem when the two computers are connected on a wired network. It is a small home network with very little traffic - dropped packets are not reported by ifconfig on neither side.

I am running a Dell Latitude D610, SuSE 10.2 with a Broadcom 4318 chipset using ndiswrapper with the bcmwl5 driver from the Dell website. The router is a Dlink D624 with the latest firmware installed. The other computer is a SuSE 10.2 machine wired on 10MB ethernet. I've appended the ssh config file for each machine at the end of the message. Please let me know if I can provide additional information.

Thanks,
Chad

SSH config for host machine (wired):


# $OpenBSD: ssh_config,v 1.22 2006/05/29 12:56:33 dtucker Exp $

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
# ForwardAgent no
# ForwardX11 no

# If you do not trust your remote host (or its administrator), you
# should not forward X11 connections to your local X11-display for
# security reasons: Someone stealing the authentification data on the
# remote side (the "spoofed" X-server by the remote sshd) can read your
# keystrokes as you type, just like any other X11 client could do.
# Set this to "no" here for global effect or in your own ~/.ssh/config
# file if you want to have the remote X11 authentification data to
# expire after two minutes after remote login.
ForwardX11Trusted yes

# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
# GSSAPIEnableMITMAttack no

# This enables sending locale enviroment variables LC_* LANG, see ssh_config(5).
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL

SSH config for client (wireless):


# $OpenBSD: ssh_config,v 1.22 2006/05/29 12:56:33 dtucker Exp $

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
# ForwardAgent no
# ForwardX11 no

# If you do not trust your remote host (or its administrator), you
# should not forward X11 connections to your local X11-display for
# security reasons: Someone stealing the authentification data on the
# remote side (the "spoofed" X-server by the remote sshd) can read your
# keystrokes as you type, just like any other X11 client could do.
# Set this to "no" here for global effect or in your own ~/.ssh/config
# file if you want to have the remote X11 authentification data to
# expire after two minutes after remote login.
ForwardX11Trusted yes

# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
# GSSAPIEnableMITMAttack no

# This enables sending locale enviroment variables LC_* LANG, see ssh_config(5).
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL

Hello and welcome to LQ. Hope you like it here.

Can anyone suggest how to troubleshoot SSH sessions frequently hanging(but always recovering) over a wireless network?
You could look at which HW and SW components are involved and how they affect (the flow of) traffic: router (auth type, firmware), PCMCIA card, kernel (driver versions, networking settings), and take samples before and after making each change to see if the situation improves. Starting with the DLink, if you use WPA-PSK, you could check out if there's a notable difference between using WEP (bad, really) and WPA. For client-side Wifi you could check if your drivers are the latest stable version and check if there's no unnecessary of scanning adjacent AP's if you have any, no unnecessary config options and such. Tightening the way the SW scanned around seemed to work for me but then again I use Wpa_supplicant, not Ndiswrapper so MMMV(VM). For networking you could check /proc/net settings like timeouts, and check if enabling Westwood helps (seemed to work for me though I have no samples to actually support that claim). And finally wrt sshd/ssh you could check if enabling any of the .*Alive settings helps.

HTH