search for: chan_output_open

...nd sock fields vary, ostate is 128 and istate is 1 in the warning messages. ======================================== Where does ostate get set? ---------------------------------------- grep ostate *.c *.h channels.c: chan_init_iostates(c); channels.c: if (ch->ostate == CHAN_OUTPUT_OPEN || channels.c: ch->ostate == CHAN_OUTPUT_WAIT_DRAIN) { channels.c: } else if (ch->ostate == CHAN_OUTPUT_WAIT_DRAIN) { channels.c: debug("X11 rejected %d i%d/o%d", ch->self, ch->istate, ch->ostat...

...quot;, c->self); if (c->sock != -1) { - if (shutdown(c->sock, SHUT_RD) < 0) + /* shutdown(sock, SHUT_READ) may return ENOTCONN if the + write side has been closed already. */ + if (shutdown(c->sock, SHUT_RD) < 0 + && (errno != ENOTCONN + || c->ostate == CHAN_OUTPUT_OPEN + || c->ostate == CHAN_OUTPUT_WAIT_DRAIN)) error("channel %d: chan_shutdown_read: shutdown() failed for fd%d [i%d o%d]: %.100s", c->self, c->sock, c->istate, c->ostate, strerror(errno)); } else {

...c->istate); + break; + } +} +static void chan_ibuf_empty1(Channel *c) { debug("channel %d: ibuf empty", c->self); @@ -221,6 +245,27 @@ } } static void +chan_wont_write1(Channel *c) +{ + debug("channel %d: wont write", c->self); + switch (c->ostate) { + case CHAN_OUTPUT_OPEN: + debug("channel %d: output open -> wait_ieof", c->self); + chan_send_oclose1(c); + c->ostate = CHAN_OUTPUT_WAIT_IEOF; + break; + case CHAN_OUTPUT_WAIT_DRAIN: + debug("channel %d: output wait_drain -> closed", c->self); + chan_send_oclose1(c); + c->osta...

...noticed that there are now cases of "[i1 o16] " as opposed to [i1 o128]" in the warning messages. Following is a copy of real warning message I collected a few minutes ago. [o128 meant the connection was closed. But o16 seems to suggest that output was open. from nchan.h: #define CHAN_OUTPUT_OPEN 0x10 #define CHAN_OUTPUT_WAIT_DRAIN 0x20 #define CHAN_OUTPUT_WAIT_IEOF 0x40 #define CHAN_OUTPUT_CLOSED 0x80 So something seems to be wrong.] chan_shutdown_read failed for #12/fd16 [i1 o16]: Transport endpoint is not connected chan_shutdown_read fail...

...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 situation, but it wasn't used since I was using the 2....

...ignores. This causes the client to stop sending window updates to the server. If the server has a sufficient amount of data still to send it will exhaust its window and stalls indefinitely. The solution is to adjust the case in channel_input_data() in channels.c. When it tests c->ostate != CHAN_OUTPUT_OPEN, instead of just returning we 'fake' the consumption of the data by moving the packet_get_string() call to above the conditional and then subtracting data_len from c->local_window and adding data_len to c->local_consumed, then doing the appropriate xfree(data) and return; There may b...

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

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

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

...buf, strlen(buf)); continue; default: @@ -834,9 +839,6 @@ channel_pre_open(Channel *c, fd_set *rea FD_SET(c->efd, readset); } /* XXX: What about efd? races? */ - if (compat20 && c->ctl_fd != -1 && - c->istate == CHAN_INPUT_OPEN && c->ostate == CHAN_OUTPUT_OPEN) - FD_SET(c->ctl_fd, readset); } /* ARGSUSED */ @@ -981,6 +983,26 @@ channel_pre_x11_open(Channel *c, fd_set } } +static void +channel_pre_mux_client(Channel *c, fd_set *readset, fd_set *writeset) +{ + if (c->istate == CHAN_INPUT_OPEN && + buffer_check_alloc(&c->...