Xvnc backend disconnects when some data copied to clipboard

[facboy]

I'm trying to use xrdp with Xvnc on CentOS 7.3, I've managed to get to the point where the VNC server is started and I briefly see the desktop before the RDP client is abruptly closed. Checking on the server I can see that Xvnc is still running, and I can connect to it successfully with vncviewer.

It seems like xrdp gets clipboard data from Xvnc that it can't decode for some reason and then bombs out:

xrdp: [20170520-18:53:30] [DEBUG] VNC got clip data
xrdp: lib_data_in: lib_mod_process_message failed

I'm using xrdp 0.9.2-5.el7 from EPEL, with TigerVNC 1.8.0 (which was released a few days ago), but I get the same problem with tigervnc-server-1.3.1-9.el7.

[facboy]

It seems that if anything tries to update the primary or clipboard selection (eg i experimented by running xclip within the RDP client) then it breaks the connection with the above error.

the output when xclip -i -selection primary is run:

xrdp -ns

[20170524-14:18:30] [DEBUG] VNC got clip data
lib_data_in: lib_mod_process_message failed
[20170524-14:18:30] [DEBUG] Closed socket 12 (AF_INET 192.168.70.12:3389)
xrdp_mcs_disconnect - socket closed
[20170524-14:18:30] [DEBUG] xrdp_mm_module_cleanup
[20170524-14:18:30] [DEBUG] VNC mod_exit
[20170524-14:18:30] [DEBUG] Closed socket 25 (AF_INET 127.0.0.1:33394)
[20170524-14:18:30] [DEBUG] Closed socket 26 (AF_UNIX)
xrdp:xrdp_encoder [0986891812]: xrdp_encoder_delete:
xrdp:xrdp_encoder [0986891812]: proc_enc_msg: xrdp_mm term
xrdp:xrdp_encoder [0986891812]: proc_enc_msg: thread exit
[20170524-14:18:31] [ERROR] Listening socket is in wrong state, terminating listener
[20170524-14:18:31] [CORE ] shutting down log subsystem...

xrdp-sesman -ns

Wed May 24 14:18:30 2017
 Connections: closed: 127.0.0.1::33394 (read: Connection reset by peer (104))
 EncodeManager: Framebuffer updates: 18
 EncodeManager:   Raw:
 EncodeManager:     Indexed RLE: 23 rects, 302.592 kpixels
 EncodeManager:                  1.15456 MiB (1:1 ratio)
 EncodeManager:     Full Colour: 30 rects, 1.94304 Mpixels
 EncodeManager:                  7.41245 MiB (1:1 ratio)
 EncodeManager:   Total: 53 rects, 2.24563 Mpixels
 EncodeManager:          8.56701 MiB (1:1 ratio)
 ComparingUpdateTracker: 748.57 Mpixels in / 180.224 kpixels out
 ComparingUpdateTracker: (1:4153.55 ratio)
[20170524-14:18:30] [INFO ] channel_thread_loop: trans_check_wait_objs error resetting
xrdp-chansrv [0986891813]: scard_deinit:
chansrv:smartcard_pcsc [0986891813]: scard_pcsc_deinit:

[nouman8]

same happening to me on archlinux since tigervnc 1.8.0 update

[facboy]

For me it doesn't matter if it's 1.3.1 (distributed with CentOS), 1.7.1 (built myself) or 1.8.0, the same problem happens with all.

[metalefty]

I confirmed the issue.

[metalefty]

CentOS 7.3
xrdp-0.9.2.git67aab0a+devel-1.el7.centos.x86_64

TigerVNC 1.3.1, 1.8.0 shows xrdp: lib_data_in: lib_mod_process_message failed error.

[metalefty]

I added some debug codes and traced the cause of lib_data_in: lib_mod_process_message failed.
https://github.com/neutrinolabs/xrdp/blob/devel/xrdp/xrdp_mm.c#L3242

/*****************************************************************************/
int
server_send_to_channel(struct xrdp_mod *mod, int channel_id,
                       char *data, int data_len,
                       int total_data_len, int flags)
{
    struct xrdp_wm *wm;

    wm = (struct xrdp_wm *)(mod->wm);

    if (is_channel_allowed(wm, channel_id))
    {
        if (wm->mm->usechansrv)
        {
            return 1; // reaches here

[20170525-07:44:49] [DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
[20170525-07:44:49] [DEBUG] Closed socket 16 (AF_INET6 ::1 port 40182)
xrdp_wm_login_mode_changed: login_mode is 10
xrdp_wm_login_mode_changed: login_mode is 11
libxrdp_query_channel - Channel 0 name rdpdr
libxrdp_query_channel - Channel 1 name rdpsnd
libxrdp_query_channel - Channel 2 name cliprdr
libxrdp_query_channel - Channel 3 name drdynvc
libxrdp_query_channel - Channel out of range 4
[20170525-07:44:49] [DEBUG] VNC got clip data
[20170525-07:44:49] [DEBUG] debug: vnc.c:777
[20170525-07:44:49] [DEBUG] debug: vnc.c:786
[20170525-07:44:49] [DEBUG] debug: xrdp_mm.c:3240
[20170525-07:44:49] [DEBUG] debug: xrdp_mm.c:3243
[20170525-07:44:49] [DEBUG] debug: vnc.c:809
[20170525-07:44:49] [DEBUG] lib_clip_data: error=1
lib_data_in: lib_mod_process_message failed

[nouman8]

@metalefty could you please have a look at issue #739 when you are free

[metalefty]

You shouldn't talk about unrelated issue.

[daniel-klein]

I have this same issue connecting to xrdp running on Arch. The connection is closed whenever I select text, which presumably invokes the clipboard. On the client side, I'm using XFreeRDP and see a ERRINFO_LOGOFF_BY_USER error.

[memnochproxy]

Occurs on F24, downgrade to xrdp-0.9.0 does not fix.
Occurs on F25.
Setting /etc/xrdp/xrdp.ini: allow_channels = false does not fix.
Setting /etc/xrdp/xrdp.ini: cliprdr=false does not fix.
Using rdesktop -r clipboard:off does not fix.
Unselecting 'printers' and 'clipboard' in mstsc.exe dialog does not fix.
xrdp-crash.log.txt

[memnochproxy]

Event xrdp-0.6.1-8.fc22.x86_64.rpm appears to break on F24 when double-clicking on text. Is something in Xorg broken?

[metalefty]

I don't think Xorg is broken. I assume the issue is between VNC server and xrdp VNC client.

[memnochproxy]

Downgraded tigervnc-server to tigervnc-1.6.0-6, with xrdp 0.6.1:
rdesktop -a16 -r clipboard:off -u root -p lanforge kedtest
Autoselected keyboard map en-us
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 23 (X_GetSelectionOwner)
Atom id in failed request: 0x0
Serial number of failed request: 21516
Current serial number in output stream: 21516

Upgraded xrdp to -0.9.2-12, tigervnc-1.6.0-6:
Autoselected keyboard map en-us
Connection established using SSL.
NOT IMPLEMENTED: RDPDR pakid 0x554c of component 0x4472
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 23 (X_GetSelectionOwner)
Atom id in failed request: 0x0
Serial number of failed request: 1128
Current serial number in output stream: 1128

[SuperDaveAU]

Just to let you know, this also happens when I highlight text in LXDE (before even pressing ctrl+c) in fedora 25.
I'm using xrdp 0.9.2-12 and tigervnc 1.8.0-1.

Is there any way at all to disable something to make it remain stable?
I'm unable to work at the moment as my service relies on me having all day RDP access to a linux box.

the last line I get in the logs before it disconnects is:

[DEBUG] VNC got clip data

[lnicola]

@SuperDaveAU You can try disabling clipboard sync.

[SuperDaveAU]

@lnicola - I have tried this and the issue persists.
I am now investigating further.

Do you know if we have come across anything that resembles a fix or work around?

[SuperDaveAU]

Oh, almost forgot.

I am also going through a Windows 2012 R2 RDP gateway to get to my fedora server running xrdp.
I'm not sure if that is of importance.

[facboy]

if you own the server, the easiest workaround is probably to use a different backend, like the Xorg one, which in my experience is about the same performance, if not slightly faster. otherwise what happens if you disable the clipboard sync using vncconfig?

[SuperDaveAU]

Right, I've got a work around. Use Xorg instead of VNC.

Firstly in your /etc/xrdp/xrdp.ini file ensure you have the following:

autorun=Xorg

[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20

then within your user directory (the user you will be logging in as), ensure you have a .Xinitrc file with the following:

#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

# exec enlightenment_start
# exec i3
# exec mate-session
# exec xmonad
# exec startlxqt
# exec startlxde
# exec awesome
# exec bspwm
# exec gnome-session
# exec gnome-session --session=gnome-classic
# exec startkde
# exec startxfce4
# exec startfluxbox
# exec openbox-session
# exec cinnamon-session
# exec pekwm
# exec catwm
# exec dwm
# exec startede
# exec icewm-session
# exec jwm
# exec monsterwm
# exec notion
# exec startdde       
# deepin-session

within that file uncomment the desktop environment you are using.

lastly add a new file, /etc/X11/Xwrapper.config with the following single line in it:

allowed_users=anybody

Once you've saved this file reboot and then try and RDP to the server.
When you are presented with the login screen, choose the session "Xorg" and then log in with your username and password.

You should now be back up and working.

[SuperDaveAU]

@facboy - Sadly I've now changed my setup as I needed the clipboard to work so I can't test this.
But for now, moving to Xorg has solved all of my problems and, you are right, it is also faster.

[lnicola]

It feels slower for me, possibly not related to neutrinolabs/xorgxrdp#87.

[memnochproxy]

that almost works; I have to set ~/.Xresources Xcursor.core: 1 to disable mouse shadow.
To re-enable -listen tcp, make sure your sesman.ini file has param= style syntax and not param1= style syntax. This syntax here allows me to accept remote X connections:

[Xorg]
param=Xorg
param=-config
param=xrdp/xorg.conf
param=-noreset
param=-listen
param=tcp
param=-logfile
param=.xorgxrdp.%s.log

[metalefty]

I found Fedora guys also see the issue and they found a workaround to avoid disconnection. It is documented in README.Fedora. Can you try this workaround?
http://pkgs.fedoraproject.org/cgit/rpms/xrdp.git/tree/README.Fedora?h=f25&id=12a8dc25dd6df49335eb643c55e18abdb084b4d5

Of course, this is just a workaround. We need fix the issue.

[metalefty]

I found that #141 is as same as this. Very long living bug.

[metalefty]

@facboy @nouman8 @daniel-klein @memnochproxy @SuperDaveAU

Hi everyone, let me know what your client is. I know some of you're using FreeRDP.

I looked into this issue, I understand the more clear condition. +clipboard switch is the point. Maybe your FreeRDP +clipboard switch is off when disconnection occurs, right? And when you turn on +clipboard switch, I assume you don't get disconnection. Can you confirm this?

The problem occurs because of xrdp doesn't handle clipboard channels correctly when client doesn't enable clipboard sharing. I'm going to fix it. Please confirm if disconnection occurs or not depending on +clipboard switch.

Thank you.

[mrmadcow]

Hi everyone, for me the error occurs using the Windows 8 rdp client (Server is arch linux with aur/xrdp 0.9.2-1 and community/tigervnc 1.8.0-2)

[metalefty]

If disconnection occurs with Windows client, maybe it is another scenario.
Do you see the log [DEBUG] VNC got clip data when disconnection occurs?
If not, it is another scenario. I'm working on disconnection after VNC got clip data case right now.

[mrmadcow]

Yes I do see that log message. And client side disabling of clipboard data (in Window rdp client settings) doesn't help, it is only fixed when I prevent clipboard handling on the server side..

[metalefty]

OK, I'll push a fix soon.

The point of the issue (disconnection after VNC got clip data) is VNC module of xrdp tries to send clipboard data to non-existent clipboard channel. Even if clipboard is disabled by client side, xrdp sends clipboard data to client. This may cause a crash.

[metalefty]

Everyone, can you try #789?

[metalefty]

Please note #789 fixes not all vnc-clipboard disconnection.

Client: FreeRDP 1.1.0 beta1

Before #789,

1. xfreerdp /v:server -clipboard -> disconnects after "VNC got clip data"
2. xfreerdp /v:server +clipboard -> disconnects

After #789,

3. xfreerdp /v:server -clipboard -> fixed!
4. xfreerdp /v:server +clipboard -> still disconnects

[metalefty]

My approach #789 was wrong. I'm making another fix. It is at least working fine for me.

[metalefty]

I've pushed #795. @facboy can you test?
Clipboard is not working with FreeRDP because of another FreeRDP bug.
Disconnection doesn't occur now even with FreeRDP.
Please test with other clients.

[facboy]

Might not be able to get to it right away as I'm a bit tied up with other things at the moment.

[metalefty]

Automatically, closed by b83b551 but need more tests by reporters. Reopening.

[mrmadcow]

#799 fixed it for me, thanks a lot!
-- windows 8 client and archlinux server, using aur/xrdp-devel-git

[metalefty]

Thank you for your testing. One more user reports that this issue seems to be fixed, I'll close this issue.

[ghost]

I still get the crashes (very soon after the connect) with commit 8c74fcb

[20170710-14:21:17] [DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
xrdp:xrdp_cache [0745691733]: xrdp_cache_add_bitmap: reset detected cache_id 0
[20170710-14:21:18] [DEBUG] Closed socket 18 (AF_INET 127.0.0.1:40186)
xrdp_wm_login_mode_changed: login_mode is 10
xrdp_wm_login_mode_changed: login_mode is 11
[20170710-14:21:18] [DEBUG] VNC got clip data
lib_data_in: lib_mod_process_message failed

Edit:
It seems to only be affected by "mouse select copy". If i do ctrl+c it does not crash. Mouse selecting text results in a crash.

[dhcolesj]

I was getting this same issue, and switched to using Xorg instead, as @SuperDaveAU suggested above. However, I can only get the clipboard to work for 1 login after a reboot of the Fedora 26 host. I don't have access to github from the PC running xrdp, so the update from there is not an option at the moment.
What's happening is the "[xrdp-chansrv]" process is going defunct on every login after that first login/logout.

And, vnc still disconnects with similar errors as @angerrit mentions above, only I don't even have to do a copy, all I have to do is select text with my mouse and it dies.

[shoemael]

#799 has also fixed this error for me.

Server: Fedora 26, tigervnc
Client: Windows 10 Remote Desktop

I just used the Fedora 26 source RPM for xrdp-0.9.2 and copied the git source on top of it and (with minor spec file changes) built a new RPM. Works perfectly. Thank you.

[OriFeniX]

It works properly

thanks so much mrmadcow!

[johncrim]

This issue, though fixed, is still quite common and problematic, due to the fact that Ubuntu 16.04 uses xrdp 0.6.1. There appear to be a number of unofficial fixes for Ubuntu 16.04 - the easiest one I found was to use this patched version:
https://launchpad.net/~hermlnx/+archive/ubuntu/xrdp

By adding this repo:

sudo add-apt-repository ppa:hermlnx/xrdp
sudo apt update

You'll get a build of xrdp 9.4 on ubuntu 16.04, which includes the fix for this issue.

[metalefty]

Thanks for the note.