sshd dies when starting gkrellm

cira ciradrak at centurylink.net
Sat Sep 2 06:13:49 AEST 2017


On 08/30/17 01:33, Philipp Marek wrote:
>> sshd also dies when certain other kinds of traffic is generated, such as
>> `man pw' using the most pager[1], and many x11 apps such as emacs.
>> However, it is stable when running simple x11 apps such as xeyes, and
>> the link its self is stable -- a terminal will stay connected without
>> issue for days, as long as not much happens in it.  Also a sshfs
>> connection dies immediately.
>>
>> ssh -Y karren
>> gkrellm &
>> *sshd dies*
> 
> My guess is that you *have* an MTU problem on your link, ie. that the
> PMTU detection doesn't work; and 1400 might still be too big.
> 
> For a test, please run
> 
>     # ping -M do -c 3 -s <size> <peer>
> 
> with size values from 600 to 1400, and then 1450 and 1472.

-M do appears to be a linux ping option -- executing from linux.

$ ping -M do -c 3 -s 600 karren.example.us
PING karren.example.us (67.77.77.777) 600(628) bytes of data.
608 bytes from 67.77.77.777: icmp_seq=1 ttl=55 time=92.8 ms
608 bytes from 67.77.77.777: icmp_seq=2 ttl=55 time=102 ms
608 bytes from 67.77.77.777: icmp_seq=3 ttl=55 time=89.9 ms

--- karren.example.us ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 89.956/94.975/102.072/5.171 ms

$ ping -M do -c 3 -s 1400 karren.example.us
PING karren.example.us (67.77.77.777) 1400(1428) bytes of data.
ping: local error: Message too long, mtu=1400
ping: local error: Message too long, mtu=1400
ping: local error: Message too long, mtu=1400

--- karren.example.us ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2037ms

$ ping -M do -c 3 -s 1300 karren.example.us
[abbreviating output]
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 99.784/106.764/113.670/5.669 ms

$ ping -M do -c 3 -s 1372 karren.example.us
3 packets transmitted, 3 received, 0% packet loss, time 6133ms
rtt min/avg/max/mdev = 99.977/101.501/102.877/1.244 ms

$ ping -M do -c 3 -s 1392 karren.example.us
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2051ms

$ ping -M do -c 3 -s 1373 karren.example.us
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2034ms

1372 appears to be the magic number.

*repeatingTestsFromFreeBSD*

-D appears to be the equivalent of "-M do"

$ ping -D -c 3 -s 1373 badger.example.us
ping: packet size too large: 1373 > 56: Operation not permitted

$ sudo bash

# ping -D -c 3 -s 1373 badger.example.us
3 packets transmitted, 0 packets received, 100.0% packet loss

# ping -D -c 3 -s 1372 badger.example.us
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 99.126/100.870/102.472/1.370 ms

# ifconfig igb0 mtu 1372  (on both ends of the link for good measure)

$ ssh karren.example.com
$ man pw

*linkDies*

packet_write_wait: Connection to 67.77.77.777 port 22: Broken pipe

Aug 30 12:31:58 karren sshd[28510]: fatal: Fssh_packet_write_poll:
Connection from 174.77.777.77 port 49798: Permission denied

Darn.

> If some size works but the higher ones don't, set the MTU of one of the
> machines to the corresponding value, and then establish an SSH connection.
> 
> 
> Also, if your traceroute has an "--mtu" option, you could run
> 
>     # traceroute --mtu <peer> 1472
> 
> to see some information; but as your ICMPs seem to get filtered, that
> might not actually help.


$ traceroute --mtu karren.example.us 1373
traceroute to karren.example.us (67.77.77.777), 30 hops max, 1373 byte
packets
 1  10.0.0.1 (10.0.0.1)  5.500 ms F=1372  7.258 ms  3.027 ms
 2  96.120.96.125 (96.120.96.125)  14.881 ms  14.909 ms  18.676 ms

And traceroute confirms that the router is restricting packets to 1380.
I also tried setting the MTUs down to 600 just to try it, but it didn't
seem to make a difference.  :(  The link still dies.

Thank you so much for your suggestions.  I think I'm going to try
compiling the portable 7.5p1 sshd from a local mirror, and see if it
behaves differently.


More information about the openssh-unix-dev mailing list