Hi, On 25.02.20 09:07, Christoph wrote: > Hi > > I have a problem since update to 1.1.0... > I use xrdp and vnc on a fedora 31. If I want to copy some text (with > menu or ctrl-c) then the connection collapses... I need to restart the > session... What can be the problem?
I've got the same problem with - Guacamole 1.1.0 client (running on Solaris 11.4.18) and - Guacamole 1.1.0 server (linked to FreeRDP 2.0 RC4), - xrdp 0.9.5, - xrdp-sesman, - Xvnc (TigerVNC 1.7.0 and 1.10.0) running on Ubuntu 18.04 LTS. I've spent a few days for tracking down the bug. As far as I can tell – it's not a Guacamole bug. The FreeRDP-2.0 RDP client library, which Guacamole 1.1.0 is linked to, seems to do much stricter checks regarding the message exchange between RDP server and itself: https://github.com/FreeRDP/FreeRDP/issues/3309 The problem is that xrdp (or rather xrdp-sesman) seems to violate the steps of informing the RDP client about its features. It only occurs when XVnc is used. When using "xorgrdp", the error is not triggered. The matter is discussed here, but not solved for Xvnc: https://github.com/neutrinolabs/xrdp/issues/873 The cause of the problem seems to lie in: https://github.com/neutrinolabs/xrdp/blob/dc9a06f6ce7c557c56350eae8f184ab5f7869f46/sesman/chansrv/clipboard.c#L478 When Xvnc is used, the message CB_MONITOR_READY seems to be transmitted before the CB_CLIP_CAPS where the RDP server states the capabilities it has. In this case, FreeRDP-2.0 assumes that there are no extended capabilities and falls back to the defaults: https://github.com/FreeRDP/FreeRDP/blob/dc89923f4a3db2c5ae5d169ea80ba4d0ad29e899/channels/cliprdr/client/cliprdr_main.c#L259 When it comes to the actual clipboard data exchange, xrdp thinks it has stated that is going to use the "long format", while FreeRDP thinks that xrdp will send messages in the "short format". This leads to a mismatch. Therefore FreeRDP quits with; Invalid short format list length: 24 [com.freerdp.channels.cliprdr.client] - cliprdr_process_format_list failed with error 1359! [ERROR] [com.freerdp.channels.cliprdr.client] - cliprdr_order_recv failed with error 1359! This makes "guacd" terminate the session. Quick fix: I deactivated the clipboard for our "Linux Remote-Tool Server" (using xrdp and TigerVNC). Another quick and dirty fix: Setting the default in FreeRDP to true: https://github.com/FreeRDP/FreeRDP/blob/dc89923f4a3db2c5ae5d169ea80ba4d0ad29e899/channels/cliprdr/client/cliprdr_main.c#L264 and recompile the FreeRDP-client2 library. Then the clipboard works again, but the compatibility of FreeRDP to other RDP servers which are only able to speak the "short format" will break. Of course, we have to find out the reason for the protocol violation. When enabling maximum logging in xrdp, xrdp-sesman and FreeRDP, we could clearly see that CB_MONITOR_READY comes indeed too early when Xvnc is used. But up to now, we have not found why it happens and in how far is it related to the backend (Xvnc vs xorgrdp). Using xorgrdp could be an option (instead of Xvnc). In the past, we had some Java-based GUIs which made problems with x11rdp, therefore we switched to xrdp + Xvnc and all problems were solved. So before switching back to something which sounds related to xorgrdp, we would have to do a lot of tests with all of our applications. Therefore we are quite eager to find out why xrdp behaves in that way. It seems it has always behaved like this, but older versions of FreeRDP have just ignored it. Kind regards, Steffen -- ------------------------------------------------------------------------ Dipl.-Inf. Steffen Moser School of Advanced Professional Studies Room: 47.3.109 Ulm University Tel: +49.731.50-32407 Albert-Einstein-Allee 45 Fax: +49.731.50-32409 89081 Ulm, Germany http://saps.uni-ulm.de/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
