On 01/08/2017 02:20 PM, Darren Tucker wrote:
> On Mon, Jan 9, 2017 at 8:54 AM, David A. Gershman
> <dagershman@xxxxxxxxxxxxx> wrote:
>> Using my _internal_ WiFi card, OpenSSH succeeds to local (internal) LAN
>> hosts, but hangs after authentication to external LAN hosts; however
>> PuTTY works for all hosts.
>
> Two possibilities I can think of:
>
> 1) MTU black hole. Check the "send-q" column on both client and
> server in netstat when it's in the hung state, compare MTUs between
> working and not working interfaces and try "ifconfig wlan0 mtu 576"
> before starting the ssh connection.
I've tried setting the MTU as stated (found that hint on another email
online)...no luck. With MTU @ either setting, the Send-Q column on the
server indicated 40 while the client is at 424.
>
> 2) ssh(1) sets the IP type of service bits around the time of your
> observed hang. In the past we have had reports of stateful devices
> not coping with the QoS of an established connection changing. Try
> "ssh -o 'IPQos lowdelay lowdelay' yourserver".
Also no luck. After a check on whether 'lowdelay' or a value was needed
(wasn't sure, so I checked), neither:
ssh -o IPQoS="lowdelay lowdelay" myserver
or
ssh -o "IPQoS lowdelay lowdelay" myserver
worked.
>
> My bet is on #1, and my guess is the default MTU is different between
> your interfaces.
The default MTU on both my native Wifi and TPE device are both 1500 as
is the server and my other systems. Since my other systems don't have
any problem, I'm presuming the access point isn't the issue either
(w.r.t. MTU). So far, MTU doesn't seem to have an effect.
--dag
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
