search for: ssh_msg_channel_window_adjust

https://bugzilla.mindrot.org/show_bug.cgi?id=3505 Bug ID: 3505 Summary: SSH_MSG_CHANNEL_WINDOW_ADJUST bottleneck Product: Portable OpenSSH Version: -current Hardware: Other OS: All Status: NEW Severity: normal Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs at mindrot.org Rep...

...box I initiate the pings from. The MTU size is 1500. The stall occurs because the client's remote window count for the tun channel goes to 0. The server's local window count is much larger. Given the discrepancy between the client and server's view of the server's window size a SSH_MSG_CHANNEL_WINDOW_ADJUST message is never sent once the client's remote window count goes to 0. The client never attempts to read off the tun device file descriptor again. After some investigation I determined that for every packet sent the client is decrementing Channel.remote_window by a value that is 4 bytes large...

Hello All, I'm using OpenSSH 4.3p2. I'm getting few messages in my syslog and it is shown below, Aug 02 11:15:19 foo sshd[4381]: Received window adjust for non-open channel 0. I found that sshd received a SSH_MSG_CHANNEL_WINDOW_ADJUST and it executes the function channel_input_window_adjust() in channels.c. I like to know how this can happen for a non-open channel. Is anything suspicious going in my network? Could anyone share the ideas? Thanks, -logu

https://bugzilla.mindrot.org/show_bug.cgi?id=1395 Summary: "session_input_channel_req: no session" should be a debug message Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: All Status: NEW Keywords: patch Severity: minor

I don't see a problem, my MTU is at the default value = 1500, but when I look at the trace from libssh2, packet type 4 received, => SSH_MSG_DEBUG packet type 91 received, => SSH_MSG_CHANNEL_OPEN_CONFIRMATION packet type 93 received, => SSH_MSG_CHANNEL_WINDOW_ADJUST packet type 99 received, => SSH_MSG_CHANNEL_SUCCESS packet type 98 received, => SSH_MSG_CHANNEL_REQUEST packet type 96 received, => SSH_MSG_CHANNEL_EOF packet type 97 received, => SSH_MSG_CHANNEL_CLOSE ==> why ? and in the log sshd, I've some strange line : Jul 7 11:52:16 TOT...

...PM To: ietf-ssh at netbsd.org Subject: Re: ssh channel window and adjustment Hi all! Thank you for your replies. Basicly your opinions confirmed my theory about the implementations and standards ;). Recently I investigated the OpenSSH client behaviour. It seems to me that OpenSSH client sends SSH_MSG_CHANNEL_WINDOW_ADJUST, when it writes more than the half of its own channel window size(the initial channel window size it is sending to its peer,when opening new channel). I think that this behaviuor may be quite incorrect. Here is an example of such situation: let's say the user using OpenSSH client sends commands...

I'm trying to send data to a server with openssh 7.9p1, but it's hanging somewhere. the client stop at the line : Jul 7 11:52:16 TOTO sshd[19553]: debug3: channel 0: will not send data after close and after 5 minutes the client closes the connection, why ? This is the trace of the server openssh : ( DEBUG3 level) Jul 7 11:52:15 TOTO sshd[31175]: debug3: fd 6 is not O_NONBLOCK Jul