search for: channel_check_window

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

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

What is the algorithm adopted by OpenSSH when it comes to deciding when to adjust the size of window? I would have thought that one'd better adjust the window size as soon as it has fallen below the maximum packet size. What worries me is a potential deadlock, in which one party does not send anything, because the window is too small for its next window space-consuming packet, while the other

..., it will notice that the output channel is no longer open, and simply return. This means it won't update c->local_window. It also won't call channel_handle_wfd, which would in any case return directly, which means that c->local_consumed won't be updated either. This means that channel_check_window won't ever send a SSH2_MSG_CHANNEL_WINDOW_ADJUST message, and eventually the server will stop sending and wait for the client to catch up, which will never happen. I could reproduce this easily on Linux by doing ssh localhost dd if=/dev/zero bs=1024 count=256 > /dev/full to see the hang,...

...s correctly, a server has to keep track of the number of window-consuming bytes that it has sent, stopping sending data when the current window is exhausted. Now how does an OpenSSH client decide when to send a window adjust packet? Looking into the OpenSSH code, the decision seems to be made in channel_check_window(), but it is not clear how and why. The exact nature of the fields local_window, local_consumed is not explained anywhere (as far as I can tell) and the correspondence with what the server is sending is not obvious. Let me give an example to make it really confusing :-) The first set of traces corr...

Hello I have ported OpenSSH 3.8p1 to a LynxOS platform. Recently I heard a report from the field that v2 is perceived to be significantly slower than v1. Is this a known issue? Are there any configuration parameters that can be modified to make v2 faster? Thanks in advance for your response Amba

...TFWD */ +#ifdef WITH_TCPFWD static void channel_post_connecting(Channel *c, fd_set * readset, fd_set * writeset) { @@ -1249,6 +1273,7 @@ packet_send(); } } +#endif /* WITH_TCPFWD */ static int channel_handle_rfd(Channel *c, fd_set * readset, fd_set * writeset) @@ -1423,6 +1448,7 @@ channel_check_window(c); } +#ifdef WITH_PROTO13 static void channel_post_output_drain_13(Channel *c, fd_set * readset, fd_set * writeset) { @@ -1437,67 +1463,118 @@ buffer_consume(&c->output, len); } } +#endif static void channel_handler_init_20(void) { channel_pre[SSH_CHANNEL_OPEN] = &...

...EN) { - 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 (!compat20) return; channel_handle_efd(c, readset, writeset); - channel_handle_ctl(c, readset, writeset); channel_check_window(c); } +static u_int +read_mu...