X11 forwarding not working

[mt50su]

Describe the problem:
Starting with release 1.0.216, X11 forwarding stopped working

Environment:
Local machine: Windows 11, Tabby 1.0.215, 1.0.216, 1.0.219, 1.0.220, VcXsrv 21.1.13
Remote Machine: Raspberry Pi 5 with Debian GNU/Linux bookworm 12.9 aarch64

To Reproduce:
1, Launch VcXsrv on the local machine.
2, Enable the X11 forwarding option in an SSH profile.
3, Use this profile to establish an SSH session and enable "X11Forwarding" in the sshd_config file on the remote machine.
4, Restart the remote sshd service and reconnect the SSH session.
5, Run an X application, such as xeyes, within the SSH session.
6, With Tabby release 1.0.215, an xeyes window appears as expected. However, with releases 1.0.216 and 1.0.219, 1.0.220 nothing happens.

[Eugeny]

Is there anything useful in the xeyes output itself, Tabby's devtools console or in https://github.com/Eugeny/tabby/wiki/Capturing-a-debug-log-from-the-SSH-backend ?

GitHub

Capturing a debug log from the SSH backend

A terminal for a more modern age. Contribute to Eugeny/tabby development by creating an account on GitHub.

[mt50su]

Is there anything useful in the xeyes output itself, Tabby's devtools console or in https://github.com/Eugeny/tabby/wiki/Capturing-a-debug-log-from-the-SSH-backend ?

GitHub**Capturing a debug log from the SSH backend**A terminal for a more modern age. Contribute to Eugeny/tabby development by creating an account on GitHub.

sure, I will capture the log, thanks

GitHub

Capturing a debug log from the SSH backend

A terminal for a more modern age. Contribute to Eugeny/tabby development by creating an account on GitHub.

[mt50su]

I have captured the logs both for release 1.0.215 & 1.0.221. It seemed there is no X11 relevant output in the v1.0.215 log during the X11 dialog establishment between tabby and Raspberry Pi. In the same scenario when I captured the log for v1.0.221 and Pi, I only got the followings after I run "xeyes":

[2025-01-24T12:15:34Z DEBUG russh::sshbuffer] > msg type 94, len 10
[2025-01-24T12:15:34Z DEBUG russh::client] < msg type 94, seqn 28, len 13
[2025-01-24T12:15:35Z DEBUG russh::sshbuffer] > msg type 94, len 10
[2025-01-24T12:15:35Z DEBUG russh::client] < msg type 94, seqn 29, len 10
[2025-01-24T12:15:35Z DEBUG russh::sshbuffer] > msg type 94, len 10
[2025-01-24T12:15:35Z DEBUG russh::client] < msg type 94, seqn 30, len 10
[2025-01-24T12:15:36Z DEBUG russh::sshbuffer] > msg type 94, len 10
[2025-01-24T12:15:36Z DEBUG russh::client] < msg type 94, seqn 31, len 10
[2025-01-24T12:15:36Z DEBUG russh::sshbuffer] > msg type 94, len 10
[2025-01-24T12:15:36Z DEBUG russh::client] < msg type 94, seqn 32, len 10
[2025-01-24T12:15:39Z DEBUG russh::sshbuffer] > msg type 94, len 10
[2025-01-24T12:15:39Z DEBUG russh::client] < msg type 94, seqn 33, len 20
[2025-01-24T12:15:39Z DEBUG russh::client] < msg type 90, seqn 34, len 31
[2025-01-24T12:15:39Z DEBUG russh::client::encrypted] confirming channel: OpenChannelMessage { typ: X11 { originator_address: "::1", originator_port: 46018 }, recipient_channel: 3, recipient_window_size: 65536, recipient_maximum_packet_size: 16384 }
[2025-01-24T12:15:39Z DEBUG russh::sshbuffer] > msg type 91, len 17
[2025-01-24T12:15:39Z DEBUG russh::client] < msg type 94, seqn 35, len 21
[2025-01-24T12:15:44Z DEBUG russh::sshbuffer] > msg type 80, len 27
[2025-01-24T12:15:44Z DEBUG russh::client] < msg type 82, seqn 36, len 1
[2025-01-24T12:15:49Z DEBUG russh::sshbuffer] > msg type 80, len 27
[2025-01-24T12:15:49Z DEBUG russh::client] < msg type 82, seqn 37, len 1
[2025-01-24T12:15:54Z DEBUG russh::sshbuffer] > msg type 80, len 27
[2025-01-24T12:15:54Z DEBUG russh::client] < msg type 82, seqn 38, len 1
[2025-01-24T12:15:57Z DEBUG russh::sshbuffer] > msg type 94, len 10
[2025-01-24T12:15:57Z DEBUG russh::client] < msg type 94, seqn 39, len 11
[2025-01-24T12:15:57Z DEBUG russh::client] < msg type 96, seqn 40, len 5
[2025-01-24T12:15:57Z DEBUG russh::client::encrypted] channel_eof
[2025-01-24T12:15:57Z DEBUG russh::client] < msg type 94, seqn 41, len 11
[2025-01-24T12:15:57Z DEBUG russh::client] < msg type 94, seqn 42, len 84

There was no more X11 relevant output then.

I have also captured the tcpdump for dialogs between v1.0.215 & Pi and v1.0.221 & pi respectively. And the same thing is there was no X11 packet can be captured between v1.0.221 & Pi when "xeyes" had been executed. In comparison with this, all the X11 packets can be captured during the X11 dialog of v1.0.215 & Pi. It can be found as below:

It seemed that v1.0.221 got no chance to initiate an X11 dialog request to the X server.

Hope the information above helps.

Thanks,
Michael

[karstennilsen]

I have the same issue. Downgrade to 215 solves it immediately. I have X11 server running on host display 6, so 127.0.0.1:6006 and this as Override X11 Display setting: localhost:6006.0

When connecting with X11 forwarding there is a display env variable set. When I connect to the corresponding 60xx port with telnet (e.g. telnet localhost 6010 when DISPLAY=localhost:10.0) I can see there is something listening (a connection is established). But it doesn't seem to be a proper tunnel to my host 127.0.0.1:6006

Host: Windows
Remote: Debian Linux 12.9 x64

[zuo000]

I occured same issue. 215 X11 works well, but broken from 216 version...

[junchao98]

same issue. 215 X11 works well, but broken at 223 version...

[Johnny-Zhang92]

The same question has been bothering me for a long time, and it wasted a lot of my time.
At first, I didn’t realize the issue was related to Tabby.
I suggest installing PuTTY instead—it works perfectly.

[nopcall]

same here

[hausen1012]

same here

[need47]

Same here. 215 does work.

[Stamgastje]

Same issue here. I just downgraded to 1.0.215 and can confirm that it works with that version. Hence, I assume it has been broken since the introduction of the russh backend.