On 5/4/22 2:40 AM, Damien Miller wrote:
On Tue, 3 May 2022, rapier wrote:
If you can similarly instrument the peer, then it might shed some light on
it. Some possibilities:
1) heaps of data in flight (e.g. bufferbloat on intervening routers)
2) a peer with a full output buffer for the channel, e.g. if it was
writing to a disk that is slower than the network. This will cause
backpressure via c->local_consumed (see end of channel_handle_wfd())
3) some stupid bug where we miss a case to update c->channel_handle_wfd
or do the math wrong in channel_check_window()
hope this helps!
It certainly does. I'm trying to narrow down the failure conditions but
it seems that it may be related to using IPv6 when there is a high
enough RTT to cause a lot of inflight data. As I get more information
I'll let you know what I find out. It's probably in my code but I wanted
to get a better grip on whats happening with these values.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
