On Thu, 19 May 2022, rapier wrote: > I think I have a fix, or at least a better band aid, for people in my > situation. If, at some point, you decide to increase the size of > CHAN_SES_WINDOW_DEFAULT this may be helpful. > > Basically, the changes to channels.h increases the size of SSH's receive > buffer, which triggers this behaviour. The changes in sshbuf.c tests to see if > the buffer is larger than ssh buffer that seems to be handling the incoming > packets. The assumption is that if it's larger then it's the receive buffer. I > then aggressively grow that buffer (4MB at a time) but no more buf->max_size. > The debug statement is so you can see what's going on but that should be > removed for production. > > If you comment out the section that grows the window aggressively you can see > the stall as the buffer grows 32k at a time. I have some concerns about > growing the buffer it such large chunks. Also, I'd ideally make it a function > of the size of c->local_window_max but I can't seem to get an extern working. I don't understand the problem and I don't understand the fix, sorry. The sshbuf_read() in packet.c will always reserve PACKET_MAX_SIZE (256k) in addition to whatever is in the buffer currently and will greedily try to fill it (up to max_size). Is there some other buffer that is growing more slowly? If so, I don't think the answer is to change the buffer code but instead to sshbuf_reserve() an appropriate size before filling data into it. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
