[Bug 1026] Sudden hang of SSH session using IPv6

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=1026

           Summary: Sudden hang of SSH session using IPv6
           Product: Portable OpenSSH
           Version: 3.9p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: pb at bieringer.de


Using IPv6 connectivity, an ssh session suddenly hangs, mostly after receiving a
bunch of content like "man <something>", "cat <something", or opening a file
with "vim" or viewing logfiles with "tail". In most circumstances, the client
window is bigger than 80x25.

I've traced it down a little bit.

1) keystrokes at the client would be still transferred to the server and
"executed", means a ":q" still closes the vi session.
But the keystrokes are not echo'ed back

2) tethereal shows following:

4070 2756.543315 3ffe:ffff::2 -> 3ffe:ffff::1 SSH Encrypted response packet len=52
4071 2756.545218 3ffe:ffff::2 -> 3ffe:ffff::1 SSH Encrypted response packet len=52
4072 2756.829811 3ffe:ffff::1 -> 3ffe:ffff::2 TCP 1029 > ssh [ACK] Seq=48912
Ack=613310 Win=8920 Len=0
4073 2756.830219 3ffe:ffff::2 -> 3ffe:ffff::1 SSH Encrypted response packet len=1115
4074 2756.830310 3ffe:ffff::2 -> 3ffe:ffff::1 SSH Encrypted response packet len=517
4075 2756.873108 3ffe:ffff::1 -> 3ffe:ffff::2 TCP 1029 > ssh [ACK] Seq=48912
Ack=615228 Win=8920 Len=0
4076 2756.885979 3ffe:ffff::1 -> 3ffe:ffff::2 TCP 1029 > ssh [ACK] Seq=48912
Ack=615332 Win=8816 Len=0
4077 2757.257207 3ffe:ffff::1 -> 3ffe:ffff::2 TCP 1029 > ssh [ACK] Seq=48912
Ack=616447 Win=8920 Len=0
4078 2757.929816 3ffe:ffff::2 -> 3ffe:ffff::1 SSH [TCP Retransmission] Encrypted
response packet len=517
4079 2759.179240 3ffe:ffff::1 -> 3ffe:ffff::2 SSH Encrypted request packet len=52
4080 2759.218775 3ffe:ffff::2 -> 3ffe:ffff::1 TCP ssh > 1029 [ACK] Seq=616964
Ack=48964 Win=15912 Len=0
4081 2759.275688 3ffe:ffff::2 -> 3ffe:ffff::1 SSH [TCP Retransmission] Encrypted
response packet len=517
4082 2759.677364 3ffe:ffff::1 -> 3ffe:ffff::2 SSH Encrypted request packet len=52
4083 2759.677741 3ffe:ffff::2 -> 3ffe:ffff::1 TCP ssh > 1029 [ACK] Seq=616964
Ack=49016 Win=15912 Len=0
4084 2759.884709 3ffe:ffff::1 -> 3ffe:ffff::2 SSH Encrypted request packet len=52
4085 2759.885097 3ffe:ffff::2 -> 3ffe:ffff::1 TCP ssh > 1029 [ACK] Seq=616964
Ack=49068 Win=15912 Len=0
4086 2760.110273 3ffe:ffff::1 -> 3ffe:ffff::2 SSH Encrypted request packet len=52

After the retransmission packet, no longer keystrokes are echo'ed back. It's not
an IPv6 MTU issue, because the MTU is already set down to 1280.

See also:
http://thread.gmane.org/gmane.network.ipv6.general/740

This happen using clients like PuTTY (W2K), openssh (on FC2 and FC3) and servers
of version openssh-3.9p1 and openssh-3.6p1 (RHEL3, RHEL4, FC3).

Any hints how to track this down? I'm partially able to reproduce this (mostly
by "tail -f maillog" and waiting some time...

For the moment I can supply the tcpdump capturing from tethereal output shown
above. But I would also be able to start an additional ssh server with strace.

BTW: I already disabled compression, because this can also lead to session hangs
on IPv6, already happen in the priv/pub key exchange phase.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.