Re: Difference in buffer behaviour between 8.89 and 8.9?

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]


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.

openssh-unix-dev mailing list

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux