Tunnel disconnects with "peer ignored channel window"
valt aran
sshdude at outlook.com
Mon Oct 20 09:35:59 AEDT 2025
Tried it with the patch and version 10.2
Error messages are something like
"channel 0: datagram length 1444 too big for window 1206 or maximum packet 32768"
Length or window can have different values.
Connection still breaks after a while.
Then I disabled the automatic disconnecting in the source code (which says the connection could deadlock in this case.)
However, no disconnects up to now. Though I seem to get lots of
"debug1: rekeying in progress
debug1: enqueue packet: ...
"
messages which I did not get before. Not sure if this is relevant or happens because the connection is now running longer.
________________________________________
From: openssh-unix-dev on behalf of valt aran
Sent: Thursday, October 9, 2025 6:15 PM
To: Damien Miller
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Tunnel disconnects with "peer ignored channel window"
Config on server:
ip tuntap add dev tunX mode tun
ip addr add A.B.C.D/24 dev tunX
ip link set dev tunX up
(+sometimes changed mtu to 1500)
in the sshd config "PermitTunnel yes" is added and sshd is restarted.
Version is 9.6p1, iirc also tried 8.7p1.
Client:
ip tuntap add mode tun tunY
ip addr add E.F.G.H/24 dev tunY
ip link set dev tunY up
Version is 9.9p1
Tunnel is setup with: ssh root at VPNIP -p 22 -f -w Y:X -N
OS where Ubuntu and Fedora
I'm going to test it with the latest OpenSSH + patch on both sides.
________________________________________
From: Damien Miller
Sent: Tuesday, October 7, 2025 11:30 PM
To: valt aran
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Tunnel disconnects with "peer ignored channel window"
On Tue, 7 Oct 2025, valt aran wrote:
> yeye I have read the html warning when signing up. I disabled it
> but seems outlook has two switch options. One for sending, one for
> viewing. Hopefully it is correct this time. Sorry for the (html)
> noise.
>
> Anyways:
>
> Hi,
>
> I have set up a ssh tunnel. It works fine, but under load it
> disconnects after a while. On the client side I get stuff like:
>
> "channel 0: rcvd too much data 1448, win 0/2097152 (excess 209960)"
>
> Usually there are lots of those message after another, but they don't
> immediately lead to a disconnect. After a while though the tunnel is
> disconnected with
>
> "disconnecting 1.2.3.4 port 4321: channel 0: peer ignored channel
> window"
>
> So this indicates the issue is on the server side?
>
> On the sshd server side I often see: "debug1: channel 0: datagram too
> big"
What exact commands are you using to start the tunnel?
What are the configurations of the tun/tap interfaces?
What OpenSSH version and OS are you using?
It's possible there's an error in the remote_window calculations.
Can you first try reproducing the problem with this patch:
diff --git a/channels.c b/channels.c
index 08636c11a..329815138 100644
--- a/channels.c
+++ b/channels.c
@@ -3055,7 +3055,9 @@ channel_output_poll_input_open(struct ssh *ssh, Channel *c)
* backpressure at read time? (i.e. read + discard)
*/
if (plen > c->remote_window || plen > c->remote_maxpacket) {
- debug("channel %d: datagram too big", c->self);
+ debug("channel %d: datagram length %zu too big for "
+ "window %u or maximum packet %u", c->self, plen,
+ c->remote_window, c->remote_maxpacket);
return 0;
}
/* Enqueue it */
Which should give some better diagnostics on what's going wrong.
I'm suspicious of this section of code in channel_input_data():
3498 if (c->datagram)
3499 win_len += 4; /* string length header */
might be double-counting the header and permanently shrinking the
channel window for each tunneled packet received. You could try
removing or commenting it out and seeing if it solves the problem.
-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
More information about the openssh-unix-dev
mailing list