SSH tunneling hangs with high Recv-Q in some scenarios

[GektorUA]

I have Debian 11 (Server) with latest from backports repo 2022.83 (in 2020.81 have same issue) Dropbear and OpenWrt (Client) with 2022.82.
Client connecting to Server and make port tunneling for proxy, mainly - it works, but in some scenarios (without high load, just launch software in few streams) Dropbear port tunneling hangs with growing Recv-Q in netstat. On clients side there is no problems with proxy, it's accessed without problems.

I have try few systems and proxy connections via ssh tunneling, there is no dependency which bandwidth of internet channel (it can be about 100 mbit/s. and software use 5-10 mbit/s maximum), it hangs almost immediately when starting software.

It can simply reproduce, but i don't know how to fix that.

If needed, i can give SSH access to problematic Server.

[mkj]

What command is used on the client?

The first thing would be to check that the client is reading all pending data from the socket - the server will stop reading from a forwarded TCP socket (causing the pending recv-q), if the client hasn't consumed its output. You could tcpdump the client and server (the proxied ports, port 22 is less useful), and check all the data received by the server has been sent out a TCP socket by the client. It's possible there are bugs in the channel/window handling though I don't recall hearing of that problem before.

[GektorUA]

Launching Speedtest site, or surfing browser by proxy, that tunneled by Dropbear.

I can give you access on Server, so you can look it by yourself. if you agreed — i will send credentials by e-mail, and then, when you connect, i will emulate tunnel hang. Because, i have spend a few weeks on it, and doesn't resolve issue (have tune kernel TCP parameters and etc, seems, it can be related to Dropbear code).

Thank you!

[mkj]

OK send me an email and I'll see what I can tell (probably later this week)

[mkj]

Thanks for help debugging this, it's a very longstanding issue.