Re: xrdp and vnc on fedora

[Christoph <ma...@gmx.de>]

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: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org