I have a number of users that are experiencing problems with terminal hangs when they output reports to the terminal. The slower the network the higher the frequesncy of the problem. Basically, the terminal will stop dead and will not recover. You have to kill the window to get rid of the terminal session. I've noticed the following: The process does not exit. Instead, acts like it did not get an xon. If you kill the process, the window does not free up. The same behavior is evident using reflections, putty, Exceed as terminal emulators. I have searched the ssh databases but have not found a match and unfortunately I will have to remove this access if a resolution is not found quickly due to the frequency of the problem.
what does "streaming" mean? what does "output reports" mean? do you have more detailed reports? do you have debugging output? what clients are involved? what servers? does the same happen with openssh 3.0.2? does the same happen with a recent snapshot?
By streaming I mean the data is substantial. Pages are output to the stdout. Unfortunately, I do not have more detailed reports as the terminal just hangs. How can I get a more detailed interaction? I am in the process of compiling 3.0.2 and will try that as soon as possible. Not sure what a snapshot is?
I think you're experiencing a problem that I first posted to the list about in March of 2001. (I got no response.) Below is the contents of the mail that I posted back then ... I believe that there is a bug in OpenSSH that affects its usage on AIX 4.3.3 - Maintenance Level 3 and higher. This bug was introduced by a change by IBM in the "/usr/lib/drivers/ptydd" driver, and it affected IBM's own telnetd daemon (reference <http://techsupport.services.ibm.com/rs6000/aix.uhuic_getrec?args=DVhuron.boulder.ibm.com+DBAIX+DA69743+STIY09667+USbin>). However, IBM chose not to fix the cause of the problem, but to instead modify telnetd to deal with the issue. The problem occurs in the sshd program; when a program on the server writes a zero-length string to the terminal, the sshd daemon abruptly closes the connection, logging no information. The following code causes the problem to exhibit itself: #include <stdio.h> #include <fcntl.h> main() { int tty_fd; int old_tty_fd; int old_stdout_fd; char str[100]; old_tty_fd = open("/dev/tty",O_RDWR); tty_fd = dup(old_tty_fd); /* 1 will be /dev/tty */ close(old_tty_fd); strcpy(str,"this is the last thing you will see if sshd is broken.\n"); fprintf(stderr,"len = %d str = %s",strlen(str),str); write(tty_fd,str,strlen(str)); strcpy(str,""); fprintf(stderr,"len = %d str = %s\n",strlen(str),str); write(tty_fd,str,strlen(str)); /* we die here on 433 */ fprintf(stderr,"if you can read this then all is good.\n"); } This bug pops up with both OpenSSH 2.3.0.p1 and 2.5.1p1 (and with the commercial ssh 1.2.26), but only when the daemon is running on 4.3.3-ML3 or higher. The same daemon works fine on AIX 4.3.2-ML2, and 4.3.3 with no ML applied. With a lot of help, I figured that the cause of the disconnect is a comparison in the "serverloop.c" file. Changing the comparison operator from a "<=" to just a "<" in the serverloop.c file fixes the issue. Here is the code block (taken from the 2.3.0p1 source distribution: +304 /* Read and buffer any available stdout data from the program. */ +305 if (!fdout_eof && FD_ISSET(fdout, readset)) { +306 len = read(fdout, buf, sizeof(buf)); +307 if (len < 0 && (errno == EINTR || errno == EAGAIN)) { +308 /* do nothing */ +309 } else if (len <= 0) { +310 fdout_eof = 1; +311 } else { +312 buffer_append(&stdout_buffer, buf, len); +313 fdout_bytes += len; +314 } Line # 309 needs to be changed to ... +309 } else if (len < 0) { Making the above change in the 2.3.0p1 and the 2.5.1p1 source distributions solves the problem, however, I don't know if there might be any other ill effect, or if the change will have an effect on other platforms. ---------- I haven't seen any resolution of this issue. I took the "cowardly" way out (meaning, I can't code) by replacing the file "/usr/lib/drivers/ptydd" on my upgraded aix boxen with one from ML-02. Meta-P.S.: This is the first time I'm using Bugzilla. Am I doing the right thing? -s-
what kind of clients are used? what protocol? how can i reproduce this? what operating systems? what happens if sshd is used in debugmode? does sshd print errors? where does sshd hang? can you trace sshd's system calls? you can get the latest snapshot from www.openssh.com/portable.html it has many bugs from 3.0.2 fixed
Upgraded one system to 3.0.2 and problem still persists. It appears that the slower the network the more often the problem presents itself. My gut feeling is that it has something to do with flow control but can't prove it. Any way I can trap where the software is when it halts?
Below is debug output from putty. I have cut the bottom of the debug file for you to work with. If you need the entire file I will send directly to you. The background is: executing ls -lR from the / directory to produce the hang. 000001e0 34 20 4f 63 74 20 32 33 20 31 38 3a 34 32 20 62 4 Oct 23 18:42 b 000001f0 6f 73 2e 6d 73 67 2e 5a 48 5f 43 4e 2e 34 2e 33 os.msg.ZH_CN.4.3 00000200 2e 33 2e 30 .3.0 Incoming packet type 17 / 0x11 (SSH1_SMSG_STDOUT_DATA) 00000000 00 00 02 00 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .....I.1..-rwxrw 00000010 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 00000020 20 20 32 30 32 20 20 20 20 20 20 32 36 33 31 36 202 26316 00000030 38 30 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 80 Oct 23 18:28 00000040 62 6f 73 2e 6d 73 67 2e 5a 68 5f 43 4e 2e 34 2e bos.msg.Zh_CN.4. 00000050 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 00000060 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 00000070 20 32 30 32 20 20 20 20 20 20 20 32 37 38 35 32 202 27852 00000080 38 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 8 Oct 23 18:37 b 00000090 6f 73 2e 6d 73 67 2e 5a 68 5f 43 4e 2e 34 2e 33 os.msg.Zh_CN.4.3 000000a0 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 000000b0 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 000000c0 20 20 32 30 32 20 20 20 20 20 20 32 36 39 33 31 202 26931 000000d0 32 30 20 4f 63 74 20 32 33 20 31 38 3a 32 37 20 20 Oct 23 18:27 000000e0 62 6f 73 2e 6d 73 67 2e 5a 68 5f 54 57 2e 34 2e bos.msg.Zh_TW.4. 000000f0 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 00000100 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 00000110 20 32 30 32 20 20 20 20 20 20 20 32 38 39 37 39 202 28979 00000120 32 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 2 Oct 23 18:37 b 00000130 6f 73 2e 6d 73 67 2e 5a 68 5f 54 57 2e 34 2e 33 os.msg.Zh_TW.4.3 00000140 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 00000150 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 00000160 20 20 32 30 32 20 20 20 20 20 20 33 31 35 31 38 202 31518 00000170 37 32 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 72 Oct 23 18:28 00000180 62 6f 73 2e 6d 73 67 2e 63 61 5f 45 53 2e 34 2e bos.msg.ca_ES.4. 00000190 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 000001a0 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 000001b0 20 32 30 32 20 20 20 20 20 20 20 33 32 39 37 32 202 32972 000001c0 38 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 8 Oct 23 18:37 b 000001d0 6f 73 2e 6d 73 67 2e 63 61 5f 45 53 2e 34 2e 33 os.msg.ca_ES.4.3 000001e0 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 000001f0 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 00000200 20 20 32 30 20 Incoming packet type 17 / 0x11 (SSH1_SMSG_STDOUT_DATA) 00000000 00 00 02 00 32 20 20 20 20 20 20 33 30 33 37 31 ....2 30371 00000010 38 34 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 84 Oct 23 18:28 00000020 62 6f 73 2e 6d 73 67 2e 63 73 5f 43 5a 2e 34 2e bos.msg.cs_CZ.4. 00000030 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 00000040 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 00000050 20 32 30 32 20 20 20 20 20 20 20 33 32 33 35 38 202 32358 00000060 34 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 4 Oct 23 18:37 b 00000070 6f 73 2e 6d 73 67 2e 63 73 5f 43 5a 2e 34 2e 33 os.msg.cs_CZ.4.3 00000080 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 00000090 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 000000a0 20 20 32 30 32 20 20 20 20 20 20 33 32 33 35 38 202 32358 000000b0 34 30 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 40 Oct 23 18:28 000000c0 62 6f 73 2e 6d 73 67 2e 64 65 5f 44 45 2e 34 2e bos.msg.de_DE.4. 000000d0 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 000000e0 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 000000f0 20 32 30 32 20 20 20 20 20 20 20 33 34 30 39 39 202 34099 00000100 32 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 2 Oct 23 18:37 b 00000110 6f 73 2e 6d 73 67 2e 64 65 5f 44 45 2e 34 2e 33 os.msg.de_DE.4.3 00000120 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 00000130 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 00000140 20 20 32 30 32 20 20 20 20 20 20 33 31 37 32 33 202 31723 00000150 35 32 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 52 Oct 23 18:28 00000160 62 6f 73 2e 6d 73 67 2e 65 6e 5f 55 53 2e 34 2e bos.msg.en_US.4. 00000170 33 2e 30 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.0.0.I..-rwxrwx 00000180 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 00000190 20 32 30 32 20 20 20 20 20 20 20 32 36 35 32 31 202 26521 000001a0 36 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 6 Oct 23 18:37 b 000001b0 6f 73 2e 6d 73 67 2e 65 6e 5f 55 53 2e 34 2e 33 os.msg.en_US.4.3 000001c0 2e 30 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .0.0.I.1..-rwxrw 000001d0 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 000001e0 20 20 32 30 32 20 20 20 20 20 20 33 32 31 35 33 202 32153 000001f0 36 30 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 60 Oct 23 18:28 00000200 62 6f 73 2e bos. Incoming packet type 17 / 0x11 (SSH1_SMSG_STDOUT_DATA) 00000000 00 00 02 00 6d 73 67 2e 65 73 5f 45 53 2e 34 2e ....msg.es_ES.4. 00000010 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 00000020 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 00000030 20 32 30 32 20 20 20 20 20 20 20 33 33 37 39 32 202 33792 00000040 30 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 0 Oct 23 18:37 b 00000050 6f 73 2e 6d 73 67 2e 65 73 5f 45 53 2e 34 2e 33 os.msg.es_ES.4.3 00000060 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 00000070 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 00000080 20 20 32 30 32 20 20 20 20 20 20 32 39 36 32 39 202 29629 00000090 34 34 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 44 Oct 23 18:28 000000a0 62 6f 73 2e 6d 73 67 2e 66 72 5f 46 52 2e 34 2e bos.msg.fr_FR.4. 000000b0 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 000000c0 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 000000d0 20 32 30 32 20 20 20 20 20 20 20 33 33 37 39 32 202 33792 000000e0 30 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 0 Oct 23 18:37 b 000000f0 6f 73 2e 6d 73 67 2e 66 72 5f 46 52 2e 34 2e 33 os.msg.fr_FR.4.3 00000100 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 00000110 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 00000120 20 20 32 30 32 20 20 20 20 20 20 33 30 38 39 34 202 30894 00000130 30 38 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 08 Oct 23 18:28 00000140 62 6f 73 2e 6d 73 67 2e 68 75 5f 48 55 2e 34 2e bos.msg.hu_HU.4. 00000150 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 00000160 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 00000170 20 32 30 32 20 20 20 20 20 20 20 33 33 35 38 37 202 33587 00000180 32 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 2 Oct 23 18:37 b 00000190 6f 73 2e 6d 73 67 2e 68 75 5f 48 55 2e 34 2e 33 os.msg.hu_HU.4.3 000001a0 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 000001b0 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 000001c0 20 20 32 30 32 20 20 20 20 20 20 33 31 39 35 39 202 31959 000001d0 30 34 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 04 Oct 23 18:28 000001e0 62 6f 73 2e 6d 73 67 2e 69 74 5f 49 54 2e 34 2e bos.msg.it_IT.4. 000001f0 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 00000200 72 2d 2d 20 r-- Incoming packet type 17 / 0x11 (SSH1_SMSG_STDOUT_DATA) 00000000 00 00 02 00 20 20 31 20 72 6f 6f 74 20 20 20 20 .... 1 root 00000010 20 32 30 32 20 20 20 20 20 20 20 33 33 31 37 37 202 33177 00000020 36 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 6 Oct 23 18:37 b 00000030 6f 73 2e 6d 73 67 2e 69 74 5f 49 54 2e 34 2e 33 os.msg.it_IT.4.3 00000040 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 00000050 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 00000060 20 20 32 30 32 20 20 20 20 20 20 33 31 39 36 39 202 31969 00000070 32 38 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 28 Oct 23 18:28 00000080 62 6f 73 2e 6d 73 67 2e 6a 61 5f 4a 50 2e 34 2e bos.msg.ja_JP.4. 00000090 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 000000a0 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 000000b0 20 32 30 32 20 20 20 20 20 20 20 33 34 33 30 34 202 34304 000000c0 30 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 0 Oct 23 18:37 b 000000d0 6f 73 2e 6d 73 67 2e 6a 61 5f 4a 50 2e 34 2e 33 os.msg.ja_JP.4.3 000000e0 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 000000f0 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 00000100 20 20 32 30 32 20 20 20 20 20 20 33 31 32 36 32 202 31262 00000110 37 32 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 72 Oct 23 18:28 00000120 62 6f 73 2e 6d 73 67 2e 6b 6f 5f 4b 52 2e 34 2e bos.msg.ko_KR.4. 00000130 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 00000140 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 00000150 20 32 30 32 20 20 20 20 20 20 20 33 32 32 35 36 202 32256 00000160 30 20 4f 63 74 20 32 33 20 31 38 3a 33 37 20 62 0 Oct 23 18:37 b 00000170 6f 73 2e 6d 73 67 2e 6b 6f 5f 4b 52 2e 34 2e 33 os.msg.ko_KR.4.3 00000180 2e 33 2e 30 2e 49 2e 31 0d 0a 2d 72 77 78 72 77 .3.0.I.1..-rwxrw 00000190 78 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 xr-- 1 root 000001a0 20 20 32 30 32 20 20 20 20 20 20 33 31 34 37 37 202 31477 000001b0 37 36 20 4f 63 74 20 32 33 20 31 38 3a 32 38 20 76 Oct 23 18:28 000001c0 62 6f 73 2e 6d 73 67 2e 70 6c 5f 50 4c 2e 34 2e bos.msg.pl_PL.4. 000001d0 33 2e 33 2e 30 2e 49 0d 0a 2d 72 77 78 72 77 78 3.3.0.I..-rwxrwx 000001e0 72 2d 2d 20 20 20 31 20 72 6f 6f 74 20 20 20 20 r-- 1 root 000001f0 20 32 30 32 20 20 20 20 20 20 20 33 32 38 37 30 202 32870 00000200 34 20 4f 63 4 Oc Incoming packet type 17 / 0x11 (SSH1_SMSG_STDOUT_DATA) 00000000 00 00 00 26 74 20 32 33 20 31 38 3a 33 37 20 62 ...&t 23 18:37 b 00000010 6f 73 2e 6d 73 67 2e 70 6c 5f 50 4c 2e 34 2e 33 os.msg.pl_PL.4.3 00000020 2e 33 2e 30 2e 49 2e 31 0d 0a .3.0.I.1.. Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d ..... Outgoing packet type 16 / 0x10 (SSH1_CMSG_STDIN_DATA) 00000000 00 00 00 01 0d .....
I'm seeing this same thing, except for even relatively small files or streaming transfers. (A few hundred kb on scp, or a few hundred kb of streamed X11 data.). In my case I'm running client 3.1p1 and the sshd is 2.0.13 (non-commercial) patched to 2.0.18. Again, using Protocol 1 is a workaround. Glenn Golden gdg@zplane.com
I'm seeing same thing. My client is 3.1p1 running on Linux 2.4.18 on i686. Server (sshd) info is listed as "2.0.13 (non-commercial)... patched to 2.0.19" running on a Linux 2.2.18 kernel on i686. Using protocol 2, scp of more than a few hundred kb usually hangs. Similarly, for X11 forwarding, after a few hundred kb of fairly intense transfer activity, it usually hangs. Using Protocol 1, neither problem is ever observed. I would agree this is a critical bug.
Can any of you replicate it with the most recent versions of OpenSSH & SSH.COM ssh? Also, please record large blocks of data (debug output, etc) as attachments rather than inserting them inline to the bug - it make it a fair bit easier to read.
Damien, I just installed 3.2.3p1, no help. Glenn
Created attachment 126 [details] AIX trace of ssh session hanging during output
This bug has been annoying me for months. I have been doing some further investigation over the last couple of days, including tracing the hang, which I have just added as an attachment. All my testing has been done using 3.4p1 running on AIX 4.3.3 ML08 (and ML09). OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f. Output generation command: perl -e 'while(1){print"O","X"x78}' This command hangs in under 2 seconds for me. Test results ------------ (openssh means the above version, ssh2 means ssh.com v3.1.2 CLIENT) rlogin testserver -> openssh localhost -> generate output -> HANG telnet testserver -> openssh localhost -> generate output -> HANG openssh testserver -> generate output -> okay openssh testserver -> openssh localhost -> generate output -> okay rlogin testserver -> ssh2 localhost -> generate output -> okay From the above, it seems that the problem is related to how the CLIENT interacts with the telnet/rlogin server on AIX. The previous entries about this only starting at ML03 and above seem to be correct. The bug is not triggered in earlier versions of AIX. Unfortunately, I have been unable to create a test case program that causes the hang to occur. However, a simple hack to channels.c does seem to fix the problem: --- channels.c.orig Tue Jul 2 14:34:32 2002 +++ channels.c Tue Jul 2 14:35:39 2002 @@ -1278,6 +1278,9 @@ buffer_len(&c->output) > 0) { data = buffer_ptr(&c->output); dlen = buffer_len(&c->output); + /* XXX - hack - do not apply - LBB */ + if (dlen > 8192) + dlen = 8192; len = write(c->wfd, data, dlen); if (len < 0 && (errno == EINTR || errno == EAGAIN)) return 1; I've not tried all possible combinations for the magic number "8192". But, a value of 16384 is too big (does not fix the problem). I've not encountered a hang after applying this patch (although I got bored after 5 or 10 minutes). I'd be interested in seeing if that hack fixes the problems others are seeing, and if there is a case for capping the max size of a write to tty devices, or if some other clean solution can be applied.
Commited fix by Markus.
Mass change of RESOLVED bugs to CLOSED