Re: Is there anything missing when forwarding my X11 connections?
This reminds me of the difference between ssh -X and ssh -Y options, maybe a look at ssh code will give you ideas. best Vladimir Dergachev On Fri, 7 Feb 2025, Christophe Lohr wrote: Hello, Please excuse the naivety of my question; I'm trying to understand how things work. I try to forward a tcp X11 connection to the server's unix socket: $ socat TCP-LISTEN:6001,fork UNIX-CONNECT:/tmp/.X11-unix/X0 Then I can use it: $ DISPLAY=localhost:1 xeyes It works well... but only for simple applications (xlogo xeyes xclock xmessage xnest...) Surprisingly, this does not works for more complex applications (Xephyr wireshark ...) These applications stop, seemingly waiting for an event that doesn't come. Increasing socat's verbosity level doesn't help me to understand, nor does strace ltrace xtrace ... Well, this seems relating to the MIT-SHM extension. My assumption: If the server thinks the client is local (due to the use of a unix socket), it activates the MIT-SHM extension without further preliminary checks (and tries to send ancillary data (shm keys or file descriptor?) via the unix socket?). Right? As a workarround, I have to generate an "untrusted" xauth cookie. Is there a better way? (Note: I'm a fan of network transparency! A next time we'll talk about vsock;-) ) Best regards Christophe
Is there anything missing when forwarding my X11 connections?
Hello, Please excuse the naivety of my question; I'm trying to understand how things work. I try to forward a tcp X11 connection to the server's unix socket: $ socat TCP-LISTEN:6001,fork UNIX-CONNECT:/tmp/.X11-unix/X0 Then I can use it: $ DISPLAY=localhost:1 xeyes It works well... but only for simple applications (xlogo xeyes xclock xmessage xnest...) Surprisingly, this does not works for more complex applications (Xephyr wireshark ...) These applications stop, seemingly waiting for an event that doesn't come. Increasing socat's verbosity level doesn't help me to understand, nor does strace ltrace xtrace ... Well, this seems relating to the MIT-SHM extension. My assumption: If the server thinks the client is local (due to the use of a unix socket), it activates the MIT-SHM extension without further preliminary checks (and tries to send ancillary data (shm keys or file descriptor?) via the unix socket?). Right? As a workarround, I have to generate an "untrusted" xauth cookie. Is there a better way? (Note: I'm a fan of network transparency! A next time we'll talk about vsock;-) ) Best regards Christophe
Re: Is there anything missing when forwarding my X11 connections?
On Fri, 7 Feb 2025 14:38:37 +0100 Christophe Lohr said: > Hello, > Please excuse the naivety of my question; I'm trying to understand how > things work. > > I try to forward a tcp X11 connection to the server's unix socket: > $ socat TCP-LISTEN:6001,fork UNIX-CONNECT:/tmp/.X11-unix/X0 > > Then I can use it: > $ DISPLAY=localhost:1 xeyes > > It works well... but only for simple applications (xlogo xeyes xclock > xmessage xnest...) > Surprisingly, this does not works for more complex applications (Xephyr > wireshark ...) > These applications stop, seemingly waiting for an event that doesn't come. > Increasing socat's verbosity level doesn't help me to understand, nor > does strace ltrace xtrace ... > > Well, this seems relating to the MIT-SHM extension. > My assumption: If the server thinks the client is local (due to the use > of a unix socket), it activates the MIT-SHM extension without further > preliminary checks (and tries to send ancillary data (shm keys or file > descriptor?) via the unix socket?). Right? using mit-shm is entirely a choice by the x client itself. invariably the right thing to do is try use the mit-shm extension - set up a xshmimage ansds then try xshmattach and see if you get an error. if you do - it's not going to work (not local) so... fall back to ximages (not xshmimages). if the apps are not doing this... that's their problem. they are obviously then clients that will never be cappable of running remotely. > As a workarround, I have to generate an "untrusted" xauth cookie. > Is there a better way? > > (Note: I'm a fan of network transparency! > A next time we'll talk about vsock;-) ) > > Best regards > Christophe -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
