Hi
does someone know if this is already fixed in fedora?
---
------
Greetz
Am 25.02.2020 13:08, schrieb Steffen Moser:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
