search for: chan_write_fail

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 does for SSHv1 - dunno what to do there) -...

.../* Close stdin. */ stdin_eof = 1; if (buffer_len(&stdin_buffer) == 0) { packet_start(SSH_CMSG_EOF); packet_send(); } } if (detach) { /* * There should be a chan_wont_read()/chan_wont_write() * API, differing only in the debug messages used. */ chan_read_failed(c); chan_write_failed(c); channel_close_fds(c); fd = open(_PATH_DEVNULL, O_RDWR, 0); if (fd < 0) return; (void) dup2(fd, STDIN_FILENO); (void) dup2(fd, STDOUT_FILENO); (void) dup2(fd, STDERR_FILENO); if (fd > 2) (void) close(fd); (void) setsid(); } } -- -DISCLAIMER: an automatically appen...

...t seen any more about this. I have looked into it a little bit. First, the file session.c (line 1849 onwards): debug("session_exit_message: release channel %d", s->chanid); channel_cancel_cleanup(s->chanid); /* * emulate a write failure with 'chan_write_failed', nobody will be * interested in data we write. * Note that we must not call 'chan_read_failed', since there could * be some more data waiting in the pipe. * djm - This is no longer true as we have allowed one pass through * the select loop...

...ep; /* Exit delay in seconds */ } Options; diff -u openssh-2.9.9p2/session.c openssh-2.9.9p2J/session.c --- openssh-2.9.9p2/session.c Sun Sep 16 16:17:15 2001 +++ openssh-2.9.9p2J/session.c Thu Sep 27 22:01:07 2001 @@ -1906,6 +1906,9 @@ */ if (c->ostate != CHAN_OUTPUT_CLOSED) chan_write_failed(c); + if (c->istate == CHAN_INPUT_OPEN && compat20) { + chan_shutdown_read(c); + } s->chanid = -1; } diff -u openssh-2.9.9p2/ssh.c openssh-2.9.9p2J/ssh.c --- openssh-2.9.9p2/ssh.c Mon Sep 24 16:04:03 2001 +++ openssh-2.9.9p2J/ssh.c Thu Sep 27 22:04:49 2001 @@ -195,6 +195,7 @@...

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

...sleep; /* Exit delay in seconds */ } Options; diff -ur openssh-3.0p1/session.c openssh-3.0p1J/session.c --- openssh-3.0p1/session.c Sun Oct 28 04:34:53 2001 +++ openssh-3.0p1J/session.c Tue Nov 13 15:55:52 2001 @@ -1919,6 +1919,9 @@ */ if (c->ostate != CHAN_OUTPUT_CLOSED) chan_write_failed(c); + if (c->istate == CHAN_INPUT_OPEN && compat20) { + chan_shutdown_read(c); + } s->chanid = -1; } diff -ur openssh-3.0p1/ssh.c openssh-3.0p1J/ssh.c --- openssh-3.0p1/ssh.c Tue Oct 9 23:07:45 2001 +++ openssh-3.0p1J/ssh.c Tue Nov 13 15:55:52 2001 @@ -195,6 +195,7 @@ fprin...

...f)); +#endif quit_pending = 1; return; } diff -ur openssh-3.0.2p1/session.c openssh-3.0.2p1J2/session.c --- openssh-3.0.2p1/session.c Sat Dec 1 16:37:08 2001 +++ openssh-3.0.2p1J2/session.c Sat Jan 19 15:56:32 2002 @@ -1929,6 +1929,8 @@ */ if (c->ostate != CHAN_OUTPUT_CLOSED) chan_write_failed(c); + if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) + chan_read_failed(c); s->chanid = -1; }

...ommand, the command can hang and will not produce an error message. I can reproduce both problems with OpenSSH 3.7.1p2 on Linux, and the code affected appears to be common with the current OpenBSD anoncvs version of OpenSSH. The write() call that fails is in chan_handle_wfd. This goes on to call chan_write_failed, which since the channel is in CHAN_OUTPUT_OPEN or CHAN_OUTPUT_WAIT_DRAIN (depending on how much output is being sent) will simply flush the data and then close the file descriptor. No error message is provided. [Note that client_process_output does provide an error message in a similar situatio...

When processing ~& with SSHv2 OpenSSH sends \004 (EOT) and does not bother sending SSH2_MSG_CHANNEL_EOF. Why is that? Why is there no direct way to get SSH2_MSG_CHANNEL_EOF or SSH2_MSG_CHANNEL_CLOSE sent? Or is there and I'm just missing it? Thanks, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant

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,

...t;, pw->pw_name, (char *)NULL); + #else "-p", "-f", "--", pw->pw_name, (char *)NULL); + #endif /* Login couldn't be executed, die. */ *************** *** 1736,1741 **** --- 1742,1757 ---- */ if (c->ostate != CHAN_OUTPUT_CLOSED) chan_write_failed(c); + #ifdef TRUSTED_HPUX + //Took two lines from a patch at: + // <http://www.math.ualberta.ca/imaging/snfs/> + //by John C. Bowman + //There is some speculation that you could possibly + //see data loss from this on usenet. But without + //this sshd does not exit on logout. + if (...

...st. + */ + packet_start(SSH_CMSG_STDIN_DATA); + packet_put_string("\004", 1); + packet_send(); + /* Close stdin. */ + stdin_eof = 1; + if (buffer_len(&stdin_buffer) == 0) { + packet_start(SSH_CMSG_EOF); + packet_send(); + } + } + + if (detach) { + chan_read_failed(c); + chan_write_failed(c); + channel_close_fds(c); + fd = open(_PATH_DEVNULL, O_RDWR, 0); + if (fd < 0) + return; + (void) dup2(fd, STDIN_FILENO); + (void) dup2(fd, STDOUT_FILENO); + (void) dup2(fd, STDERR_FILENO); + if (fd > 2) + (void) close(fd); + (void) setsid(); + } +} + static void client_inpu...

System: Linux 2.4.18, openssh-3.4p1 Problem: I use "ssh" and "tar" to backup remote directory trees to a local hard-disk/file-system: # ssh remote.server.org "tar -cz /home" >/backup/remote.tar.gz If the backup-file-system runs out of space before the backup completes, ssh starts hanging (waiting for the stdout-write to complete). Analysis: In

...================================================ RCS file: /home/markus/cvs/ssh/session.c,v retrieving revision 1.143 diff -u -r1.143 session.c --- session.c 30 Jun 2002 21:54:16 -0000 1.143 +++ session.c 12 Jul 2002 16:35:32 -0000 @@ -1629,11 +1629,15 @@ /* * emulate a write failure with 'chan_write_failed', nobody will be * interested in data we write. - * Note that we must not call 'chan_read_failed', since there could + * Note that for the non-pty case we must not call 'chan_read_failed', + * since there could * be some more data waiting in the pipe. */ if (c-&g...

...quot;protocol error: chan_rcvd_ieof %d for ostate %d", c->self, c->ostate); nchan.c: switch (c->ostate) { nchan.c: c->ostate = CHAN_OUTPUT_WAIT_IEOF; nchan.c: c->ostate = CHAN_OUTPUT_CLOSED; nchan.c: error("internal error: chan_write_failed %d for ostate %d", c->self, c->ostate); nchan.c: switch (c->ostate) { nchan.c: c->ostate = CHAN_OUTPUT_CLOSED; nchan.c: error("internal error: chan_obuf_empty %d for ostate %d", c->self, c->ostate); nchan.c: * ACTIONS: should n...

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'd like a feature whereby ssh puts itself in the background after the first successful X11 (or other port) forwarding. The reason for this is simple: error handling. If the application fails to open the X display and exits, then the client can still exit with the application's exit code. But if the application opens the X display successfully, then it can just display any errors by

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

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

...no == EAGAIN)) - return 1; - if (len <= 0) { - debug2("channel %d: ctl read<=0", c->self); - if (c->type != SSH_CHANNEL_OPEN) { - debug2("channel %d: not open", c->self); - chan_mark_dead(c); - return -1; - } else { - chan_read_failed(c); - chan_write_failed(c); - } - return -1; - } else - fatal("%s: unexpected data on ctl fd", __func__); - } - return 1; -} - -static int channel_check_window(Channel *c) { if (c->type == SSH_CHANNEL_OPEN && @@ -1785,10 +1779,130 @@ channel_post_open(Channel *c, fd_set *re if (!compat2...