[ 
https://issues.apache.org/jira/browse/GUACAMOLE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17343802#comment-17343802
 ] 

Nick Couchman commented on GUACAMOLE-1345:
------------------------------------------

{quote}
I installed this docker image via Compose: 
https://github.com/oznu/docker-guacamole / 
https://hub.docker.com/r/oznu/guacamole/

Although it is no longer maintained, it installs latest versions.
{quote}

Well, you may want to switch to something that is maintained, or use the 
official images. I'm not saying the problem doesn't existing in the official 
images - it may still be there.

{quote}
I checked logfiles of the host (syslog) and the logs within the container but 
could not find version numbers.  According to the dockerfile on github this is 
1.3.0. Where can I find version numbers?
{quote}

The version numbers should be somewhere in the output of the logs. It sounds 
like it is probably 1.3.0, but it's hard to say unless you track that down. You 
might try restarting the containers and looking at the logs very quickly after 
container startup, as the version number is usually displayed when guacd is 
started and when the Guacamole Client WAR is deployed.

{quote}
Disabling Glyph Cache via the webUI, then connect, same issue.
{quote}

Thanks for confirming that.

{quote}
Thanks for reporting this. I've managed to reproduce it with Guacamole, but not 
with the Microsoft client. It's a buffer overflow in the VNC code for large 
copy-and-paste operations.
{quote}

This doesn't make sense to me. If you're using RDP to connect, then the issue 
will not be in the VNC code in Guacamole. Guacamole does not use any of the VNC 
protocol code when connecting to xrdp, no matter what xrdp is using on the 
back-end. I've responded to the Github issue you mentioned, above, to get some 
clarification on that.

Also, while this does seem to clear xrdp of any issues, it doesn't necessarily 
mean that Guacamole is to blame. It also could be the FreeRDP library - we've 
encountered several issues in the past year or so with various versions of the 
FreeRDP library.

It would be good to find log messages around the connection drop, particularly 
for guacd, as that will help identify what is happening when the connection 
drops (segfault and core dump, or server disconnect, etc.).

> Disconnect after selecting large amount of text (Ubuntu 21.04, xrdp, x11vnc) 
> -----------------------------------------------------------------------------
>
>                 Key: GUACAMOLE-1345
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1345
>             Project: Guacamole
>          Issue Type: Bug
>            Reporter: zilexa
>            Priority: Minor
>
> Ubuntu Budgie 21.04 (but same issue on 20.10), xrdp 0.9.12 and guacamole 
> installed via docker.
> All I did on my homeserver:
>  {{sudo apt install xrdp && sudo apt install x11vnc}}
> Changed the xrdp.ini file, x11vnc section to connect to port 5900. Goal is to 
> share the local desktop session that is currently running (instead of a new 
> remote session):
> [X11vnc]
> name=X11vnc
> lib=libvnc.so
> ip=127.0.0.1
> port=5900
> I have Guacamole in Docker running on the server and access guacamole via my 
> laptop within my LAN. Via guacamole I simply connect to xrdp protocol, 
> {{rdp://192.168.88.2}}. Connection works instantly, it is plenty fast.
> Only issue is this one:
>  [#755|https://github.com/neutrinolabs/xrdp/issues/755]
> As soon as I select a large/semi-large amount of text, I am disconnected 
> within seconds.
>  I can reconnect, but after a fixed amount of time (about 10-15sec) I always 
> get disconnected.
>  Unless I use the little time I have after reconnecting to select a single 
> word, when I do that, connection stays.
> This was fixed in xrdp.
> When I connect (using guacamole) directly with x11vnc: 
> {{vnc://192.168.88.2:5900}} I do not have this issue. I prefer the 
> xrdp>x11vnc route though because it is slightly faster.
>  
> I wonder if this is a guacamole issue?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to