[Cialug] X11 applications over SSH very slow to start

Thu Mar 14 14:05:07 CDT 2013

To completely fix it i ended up having to take measures slightly more 
drastic than i'd have liked, but this combination worked:

# echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf
# echo 'AddressFamily inet' >> /etc/ssh/sshd_config
# sed -ie '/::/s/^/#/' /etc/hosts
# reboot

On 2013-03-14 at 12:54:45, Barry Von Ahsen wrote:
>is ssh still binding to IPv6 though?  on my wheezy box, I netstat
>shows
>
>tcp        0      0 0.0.0.0:22              0.0.0.0:*              
>LISTEN tcp6       0      0 :::22                   :::*              
>     LISTEN
>
>even though I've never configured anything for IPv6.  I'm sure it
>snuck in during some random upgrade.  I understand why distros want
>to support IPv6, but not why they don't disable it, then let those
>who 1) want it and 2) know how to configure it override that  /rant
>
>
>-barry
>
>On Mar 14, 2013, at 12:16 PM, Daniel A. Ramaley wrote:
>> Sorry for the noise, but i got this figured out about 5 minutes
>> after sending my call for help.
>> 
>> I did a few comparisions with ssh -vvv to a server where everything
>> works as expected. Turns out the problem is IPv6. Specifically, that
>> IPv6 is enabled in the kernel, but dropped by iptables. If i turn
>> off iptables, X11 over SSH works. If i remove "::1 localhost" in
>> /etc/hosts, it works. I haven't tried disabling IPv6 in the kernel,
>> but presumably that will also work. I'm not sure why SSH was trying
>> to do anything over IPv6 when i was making my connection over IPv4,
>> but now that i know the issue is IPv6-related it will be easy
>> enough to fix permanently.
>> 
>> Again, sorry for the noise.
>> 
>> On 2013-03-14 at 12:04:38, Daniel A. Ramaley wrote:
>>> I have a Debian Testing server that i'm SSH'ing to. The box is on a
>>> LAN with gigabit ethernet, so the network is nice and fast. SSH
>>> login is very fast. X11 applications, once started, perform very
>>> fast. The problem is that X11 applications are *very* slow to
>>> start. By "very" i mean from when i run a command there will be a
>>> 5 to 15 *minute* delay before the application appears. Once
>>> started, however, everything is nice and fast as one would expect
>>> on a gigabit LAN.
>>> 
>>> I tried setting "UseDNS no" in sshd_config on the server and
>>> restarting; no effect.
>>> 
>>> I tried SSH'ing with "-vvv". Here's the debug output i get when
>>> running an X11 program (emacs, but i don't think that matters since
>>> all X11 applications seem to be affected):
>>> 
>>> 
>>> debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max
>>> 16384 debug1: client_request_x11: request from 127.0.0.1 42410
>>> debug2: fd 7 setting O_NONBLOCK
>>> debug3: fd 7 is O_NONBLOCK
>>> debug1: channel 1: new [x11]
>>> debug1: confirm x11
>>> debug2: channel 1: rcvd eof
>>> debug2: channel 1: output open -> drain
>>> debug2: channel 1: obuf empty
>>> debug2: channel 1: close_write
>>> debug2: channel 1: output drain -> closed
>>> debug1: channel 1: FORCE input drain
>>> debug2: channel 1: ibuf empty
>>> debug2: channel 1: send eof
>>> debug2: channel 1: input drain -> closed
>>> debug2: channel 1: send close
>>> debug3: channel 1: will not send data after close
>>> debug2: channel 1: rcvd close
>>> debug3: channel 1: will not send data after close
>>> debug2: channel 1: is dead
>>> debug2: channel 1: garbage collecting
>>> debug1: channel 1: free: x11, nchannels 2
>>> debug3: channel 1: status: The following connections are open:
>>> #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)
>>> #1 x11 (t4 r3 i3/0 o3/0 fd 7/7 cc -1)
>>> 
>>> debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max
>>> 16384 debug1: client_request_x11: request from 127.0.0.1 42412
>>> debug2: fd 7 setting O_NONBLOCK
>>> debug3: fd 7 is O_NONBLOCK
>>> debug1: channel 1: new [x11]
>>> debug1: confirm x11
>>> debug2: channel 1: rcvd eof
>>> debug2: channel 1: output open -> drain
>>> debug2: channel 1: obuf empty
>>> debug2: channel 1: close_write
>>> debug2: channel 1: output drain -> closed
>>> debug1: channel 1: FORCE input drain
>>> debug2: channel 1: ibuf empty
>>> debug2: channel 1: send eof
>>> debug2: channel 1: input drain -> closed
>>> debug2: channel 1: send close
>>> debug3: channel 1: will not send data after close
>>> debug2: channel 1: rcvd close
>>> debug3: channel 1: will not send data after close
>>> debug2: channel 1: is dead
>>> debug2: channel 1: garbage collecting
>>> debug1: channel 1: free: x11, nchannels 2
>>> debug3: channel 1: status: The following connections are open:
>>> #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)
>>> #1 x11 (t4 r3 i3/0 o3/0 fd 7/7 cc -1)
>>> 
>>> debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max
>>> 16384 debug1: client_request_x11: request from 127.0.0.1 42414
>>> debug2: fd 7 setting O_NONBLOCK
>>> debug3: fd 7 is O_NONBLOCK
>>> debug1: channel 1: new [x11]
>>> debug1: confirm x11
>>> debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max
>>> 16384 debug1: client_request_x11: request from 127.0.0.1 42416
>>> debug2: fd 8 setting O_NONBLOCK
>>> debug3: fd 8 is O_NONBLOCK
>>> debug1: channel 2: new [x11]
>>> debug1: confirm x11
>>> debug2: channel 2: rcvd eof
>>> debug2: channel 2: output open -> drain
>>> debug2: channel 2: obuf empty
>>> debug2: channel 2: close_write
>>> debug2: channel 2: output drain -> closed
>>> debug1: channel 2: FORCE input drain
>>> debug2: channel 2: ibuf empty
>>> debug2: channel 2: send eof
>>> debug2: channel 2: input drain -> closed
>>> debug2: channel 2: send close
>>> debug3: channel 2: will not send data after close
>>> debug2: channel 2: rcvd close
>>> debug3: channel 2: will not send data after close
>>> debug2: channel 2: is dead
>>> debug2: channel 2: garbage collecting
>>> debug1: channel 2: free: x11, nchannels 3
>>> debug3: channel 2: status: The following connections are open:
>>> #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)
>>> #1 x11 (t4 r3 i0/0 o0/0 fd 7/7 cc -1)
>>> #2 x11 (t4 r4 i3/0 o3/0 fd 8/8 cc -1)
>>> 
>>> 
>>> After about 6 or 7 minutes and all of those debug lines, then emacs
>>> finally opened. Any ideas?
>>> 
>>> __
>>> Daniel A. Ramaley
>>> Network Engineer 2
>>> 
>>> Dial Center 112, Drake University
>>> 2407 Carpenter Ave / Des Moines IA 50311 USA
>>> Tel: +1 515 271-4540
>>> Fax: +1 515 271-1938
>>> E-mail: daniel.ramaley at drake.edu
>>> _______________________________________________
>>> Cialug mailing list
>>> Cialug at cialug.org
>>> http://cialug.org/mailman/listinfo/cialug
>> 
>> __
>> Daniel A. Ramaley
>> Network Engineer 2
>> 
>> Dial Center 112, Drake University
>> 2407 Carpenter Ave / Des Moines IA 50311 USA
>> Tel: +1 515 271-4540
>> Fax: +1 515 271-1938
>> E-mail: daniel.ramaley at drake.edu
>> _______________________________________________
>> Cialug mailing list
>> Cialug at cialug.org
>> http://cialug.org/mailman/listinfo/cialug
>
>_______________________________________________
>Cialug mailing list
>Cialug at cialug.org
>http://cialug.org/mailman/listinfo/cialug
__
Daniel A. Ramaley
Network Engineer 2

Dial Center 112, Drake University
2407 Carpenter Ave / Des Moines IA 50311 USA
Tel: +1 515 271-4540
Fax: +1 515 271-1938
E-mail: daniel.ramaley at drake.edu