similar to: Work around Linux kernel bug provoked by nchan.c

When I encounter the problem with TCP port forwarding locking up, I'll see this on the client window (if I haven't invoked ssh with -q): chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected This is with Blowfish encryption. I have to kill and restart the client when this happens. Phil

I have been using OpenSSH for a while, and I would like to thank you for the great package. Here is a report of mysterious warning message lines, I get while I use OpenSSH. They don't seem to be serious, but annoying nevertheless. version: openssh-1.2.1pre27 OS Linux standard 2.2.14 #18 SMP Thu Jan 6 06:07:45 JST 2000 i586 unknown (compiled with gcc 2.95.2) Compiler gcc -v Reading

I am running OpenSSH 2.9p1 on SunOS 5.7 w/4-24-2001 patch cluster. Like many other users I am seeing the hanging session on logout with background processes. This is a huge problem for me as I centrally manage 50+ machines with rdist across ssh. Instead of just complaining about the problem I thought I would put my CS degree to use and try to track down the problem myself. For starters,

Hi! I have problems with connections being left open with both 2.2.0p1 and the latest snapshot when using agent-forwarding. (I didn't use this with older versions, so I don't know whether this problem is older.) Scenario: I have a secret key that I run with ssh-agent on host "host-A". I then connect to "host-B" using 'slogin -A host-B'. When executing a

The command "ssh ls -l /doesnotexist" gives various responses: Running from a 200 MHz PentiumPro with dsa key added to ssh-agent: Mistakes worst to fast machine: To a faster 600 MHz dual processor i686 600 MHz machine: ls: /doesnotexist: No such file or directory -- correct nothing at all -- wrong ls: select: Bad file descriptor -- wrong

In the changelog, there is an entry: 20001129 - (djm) Back out all the serverloop.c hacks. sshd will now hang again if there are background children with open fds. Does this mean that this is regarded as expected (and correct) behavior, that should not change in the future, or does it mean that this behavior is a known problem that someone will eventually fix? --Adam -- Adam McKenna

I'm logging in from an irix machine to a linux machine (both running openssh-2.5.1p2) and am unable to run any X applications. I ran a verbose session and this happens: debug: fd 6 IS O_NONBLOCK debug: channel 0: new [X11 connection from host port 4572] debug: X11 connection uses different authentication protocol. debug: X11 rejected 0 i1/o16 debug: channel 0: read failed debug: channel 0:

Hi, Thank you for the great OpenSSH package. I obtained 1.2.2 and tried it on linux 2.2.14. I had reported earlier that I saw "Transport endpoint is not connected" warning messages were observed on the linux 2.2.14 kernel with earlier release of openssh. The same happens when I used the port-forwarded HTTP connection. But this time, after accessing such http connections, I noticed

The 4.6p1 sshd is logging this error during remote commands or file transfers: error: channel 0: chan_read_failed for istate 3 Platform is Solaris 8, 4.6p1 + OpenSSL 0.9.8d. The commands and transfers work correctly, so the error message appears to be spurious. The error message does not appear when processing logins. Otherwise 4.6p1 is running without any apparent problems. This error

I'm still seeing problems when I use TCP connection forwarding across SSH to surf the web. I see lots of error messages of the form channel 1: chan_shutdown_read: shutdown() failed for fd7 [i1 o128]: Transport endpoint is not connected And I see occasional connection lockups. Both ends are running openssh-2.1.1p1. Phil

Markus, How's this patch? - a chan_wont_read()/chan_wont_write() API is added that is very much like chan_read_failed()/chan_write_failed(), but for the debug messages and chan_wont_*() don't ever call error() The 3.0.2p1 channel_pre_x11_open() uses chan_*_failed() but looks like it ought to use chan_wont_*() instead :) - forkoff() no longer fakes EOF for SSHv2 (still

As you are now probably aware, the portability team for openssh still has not fixed the hang-on-exit bug in the 2.9.9p2 release. Attached is a patch for 2.9.9p2 that fixes the hang-on-exit bug for Linux systems. It also adds a useful exit delay feature that has also not yet been incorporated into the main sources. For more information, see the SNFS (secure NFS) web page:

Attached is the patch I've been using to fix the error message seen in the subject line. It seems (!) to have caused no problems with the previous openssh snapshot version openssh-SNAP-20001016, 2.3.0p1 and the latest snapshot (openssh-SNAP-20001114). The patch adds 3 lines to nchan.c in a switch stmt (line 100). It simply caters for the cases where the input channel state is

Using OpenSSH_8.3p1 I had an open (working) connection to some other box; after a bit of inactivity, some device in the middle seems to have forgotten about the TCP connection (NAT) and broke it. I've got an EscapeChar defined, though; so first I tried to send a BREAK and, when that didn't help (TCP already gone, packets get lost!), I tried (just out of curiosity) a Rekey. Now I can see

The hang-on-exit bug still hasn't been fixed in OpenSSH-3.0p1... :-( Here again is the patch to fix this bug under Linux, updated for OpenSSH-3.0p1. This has been exhaustively tested for six months now. It also add an exit delay option that can be useful. The patch does not lead to data loss under Linux. Please see the Secure NFS page (SNFS) for further details:

I always forget those CC's :(( ---------- Forwarded message ---------- Date: Tue, 22 Aug 2000 18:39:14 +0200 (CEST) From: Igmar Palsenberg <i.palsenberg at jdimedia.nl> To: zack at wolery.cumb.org Subject: Re: Work around Linux kernel bug provoked by nchan.c Hi, Regarding this bug : the man page states : On success, zero is returned. On error, -1 is returned and errno is set

For some time I have routinely websurfed across a forwarded TCP connection using SSH. The other end of the TCP tunnel connects to a Squid proxy cache on the same machine. This usually works. But I see lots of error messages on each end of the form Jun 13 13:22:02 tunnel sshd[32378]: error: channel 0: chan_shutdown_read: shutdown() failed for fd5 [i1 o128]: Transport endpoint is not connected

Anybody seen this error before and know how to fix it? I only seem to get this under AIX (AIX 4.2.1 - haven't tried higher levels yet). I have not seen this under Solaris and Linux yet. debug1: Received X11 open request. debug1: fd 4 setting O_NONBLOCK debug1: fd 4 IS O_NONBLOCK debug1: channel 0: new [X11 connection from 127.0.0.1 port 3419] debug1: X11 connection uses different

When I run this command: ssh -1 -v -n -l root njdb1b /usr/bin/X11/xterm -sb -sl 1000 -T njdb1b -e find /etc An xterm appears on my screen, the contents of /etc scroll by and then ssh exits. When I invoke the same command with the -2 option, the xterm appears (and disappears) but ssh never exits. netstat says the (ssh) connection is still established but the xterm is no longer

This to announce a test release of 2.1.0p1 before making it widely available. This release includes many fixes to problems reported over the last week. In particular: - spurious error and coredumps caused by the inbuilt entropy gathering - RSAref detection - Compilation fixes for Solaris and others It also contains (completely untested) support for compiling without RSA support. This may be