Hi

sorry for the late reply. I made my answers inline:

Ulrich Sibiller <ulrich.sibiller@gmail.com> hat am 17. März 2025 um 21:35 geschrieben:

Hello again,

I had a look at the logfile. It's been a while since I worked on the
clipboard code. But I _think_ there are a few things you should test:

• restrict clipboard to text only: add X2GO_NXAGENT_DEFAULT_OPTIONS+="
  -textclipboard" to /etc/x2go/x2goagent.options on the server side and
  start a NEW session (no reconnect). Does that help?

No, same behavior.

But I kept this setting for all further tests.

• not sure what exactly you have been doing while creating the sessionlog. But I can seen "caja" on the server side requesting clipboard.
  Please try to run a session without caja (which is a file manager,
  unclear what it does with selections).

See new session.log without any caja mention, from a client with twm/xterm to a session with twm on the server. There I started xterm, then did a "libreoffice --calc /home/localadmin/test.ods" and did several ctrl+c ctrl+v in that calc document.

• it _looks_ like something on the client side is requesting theclipboard when you are doing your tests. The question is what program
  is doing that. If possible run a few programs on the client side,
  preferably only a very simple session (fvwm twm or so) and an xterm.
  Run x2goclient from there.
  To find out what program on the client side is requesting the
  clipboard you can check the server log file for lines like this:
  nxagentHandleSelectionRequestFromXServer: Received
  SelectionRequestEvent from real server: selection [529][CLIPBOARD]
  target [469][TARGETS] requestor
  [display[nx,options=/tmp/.x2go-localadmin/C-localadmin-50-1742211621_stDMATE_dp24/options:50.0]/0xe09e31]
  destination [386][GDK_SELECTION] time [13640727]. The bold number is
  the requestor. You can check that with xwininfo -id <number> on the
  client.

The bold marking went missing, so I just  tested all ids.

From client mate to server twm I always get "No such window ...", e.g.

me@client:~$ xwininfo -id 531
X Error: 9: Bad Drawable
Request Major code: 14
ResourceID in failed request: 0x213
Serial number of failed request: 3
xwininfo: error: No such window with id 0x213.

Then I tested from the twm/xterm client to a twm/xterm session on the server, see the attached Bug1633_nxagentHandleSelectionRequestFromXServer.log

• there's an option to include the clipboard content (or rather thedata being transferred) in the session log in DEBUG mode. This helps
  in identifying what stage we are in. Change #undef
  PRINT_CLIPBOARD_CONTENT_ON_DEBUG to #define and recompile

Done, see new session.log.

• while at it you could also try to change the timeout for theclipboard transfer. I hardcoded 5s when I wrote all this and it was ok
  for me ever since. But YMMV. #define CONVERSION_TIMEOUT 5000. In your
  log I see errors like this "nxagentConvertSelection: got new request
  before timeout expired on previous request, notifying failure to
  client [20] (addr [0x557c39ea2f40] PID [18630] Cmd
  [/usr/lib/libreoffice/program/soffice.bin])". This means that the
  previous clipboard-related communication has not finished when soffice
  starts another request which then is denied. So this indicates that
  some answer from the client side is still due. I suspect that this
  answer is never sent so your diagnosis that every second paste is
  working might in fact resemble a 5s pattern. Meaning: you can only
  successfully paste every 5s, but not quicker. So I suggest to decrease
  the timeout to 2s or so and see if that makes a difference for you.
  One thing here is strange here, though: Doing a copy in soffice on the
  server side makes soffice the clipboard owner. So while you are
  working inside soffice there should be no communication to the client
  that awaits any answer. Which again leads me to the suspicion that
  there's some clipboard manager involved.

First I tried waiting for 15 seconds after copying: this does NOT help.

Then I recompiled with #define CONVERSION_TIMEOUT 2000, same behavior, see new session.log

• x11 clipboard transfers are size restricted. That means that biggerselections are to be transferred to the requestor in multiple packets.
  nx does not support this currently, so you are restricted to 256kB. Is
  it possible that your selection is bigger than that?

No, its always just a few characters.

• I also see SelectionClear requests from the client side. Which alsoindicates there's something dealing with clipboard on the client side.

I still see SelectionClear in the new twm/xterm to twm/xterm session.log, but I'm not sure which side they are from.

• I played around with these tools:https://github.com/phillbush/xcliputils Using xclipowner -w you can
  watch if the clipboard owner changes. Run that on the client and then
  do clipboard stuff in libreoffice on the server. The owner as printed
  by xclipowner should never change except for the first time. If it
  does we have another indication of a clipboard-manager-in-the-middle
  attack ;-)

From client Mate to server twm a successful ctrl+c results in

0x03C0016A

and a failed ctrl+c results in a

0x00000000
0x03C0016A

From twm/xterm client to a twm/xterm session on the server both failed and successful ctrl+c results in

0x00E0016A

Thanks and greets