--On Dienstag, 19. April 2005 17:22 +0900 "JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" <[EMAIL PROTECTED]> wrote:
On Mon, 11 Apr 2005 17:36:33 +0200, Peter Bieringer <[EMAIL PROTECTED]> said:
has anyone seen this? I have such problems since long time and don't know the reason. Today, I debugged a little bit and it's very strange:
one side: Fedora Core 3 running 2.6.10-1.770_FC3 openssh-3.9p1-8.0.1 other side: Fedora Core 2 running 2.6.10-1.771_FC3 and openssh-3.6.1p2-34
Connection: FC2 (client) to FC3 (server)
Login is working, editing a file with vi, suddenly I do no longer get any reponse from typed chars.
(snip)
The only equal thing is that the boxes are located in the same data center having the same IPv6 connectivity.
Has noone ever seen such?
One typical reason for this type of problems is because PMTU discovery does not work due to a buggy/mis-configured router/firewall which drops ICMPv6 packet too big messages. You may want to check whether this is the case or not in your environment.
No it isn't. I turned down MTU on all links to 1280. It happen again afterwards.
I've recorded now an IPv6 SSH TCP stream and think, it is a problem in the OpenSSH code.
After an TCP transmission, key strokes are acknowledged, but not echo'ed locally. The response packets are missing.
Here the tethereal output:
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
Looks like something is going wrong in the SSH layer. As an strace earlier show, ssh client still receives a char, but do not print it.
I still don't know where to debug deeper.
Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ --------------------------------------------------------------------- The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
