search

neutrinolabs / xrdp

xrdp: an open source RDP server
http://www.xrdp.org/
Apache License 2.0
5.75k stars 1.73k forks source link

Slow work when connected via RDP client Microsoft Windows #2045

Closed skochko closed 3 years ago

skochko commented 3 years ago

Hello! I am running xrdp in a docker container (fedora 33) and faced a slow performance issue when connecting Windows clients. When connected via reminna, everything fast works. What can I do to fix this? There is an error in the logs

xrdp[30]: [ERROR] Fastpath frame acks is disabled
xrdp[30]: [DEBUG] compress_rdp failed, sending uncompressed data. type 2, flags 1
xrdp -v
xrdp 0.9.17
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2020 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --build=x86_64-redhat-linux-gnu
      --host=x86_64-redhat-linux-gnu
      --program-prefix=
      --disable-dependency-tracking
      --prefix=/usr
      --exec-prefix=/usr
      --bindir=/usr/bin
      --sbindir=/usr/sbin
      --sysconfdir=/etc
      --datadir=/usr/share
      --includedir=/usr/include
      --libdir=/usr/lib64
      --libexecdir=/usr/libexec
      --localstatedir=/var
      --sharedstatedir=/var/lib
      --mandir=/usr/share/man
      --infodir=/usr/share/info
      --enable-fuse
      --enable-pixman
      --enable-painter
      --enable-vsock
      --with-socketdir=/run/xrdp
      build_alias=x86_64-redhat-linux-gnu
      host_alias=x86_64-redhat-linux-gnu
      CC=gcc
      CFLAGS=-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
      LDFLAGS=-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
      LT_SYS_LIBRARY_PATH=/usr/lib64:
      PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig

  Compiled with OpenSSL 1.1.1l  FIPS 24 Aug 2021

Full logs

xrdp[30]: [INFO ] sesman connect ok
xrdp[30]: [DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait...
xrdp[30]: [INFO ] sending login info to session manager, please wait...
xrdp[30]: [DEBUG] return value from xrdp_mm_connect 0
xrdp[30]: [DEBUG] Login state change request WMLS_START_CONNECT -> WMLS_CONNECT_IN_PROGRESS
xrdp-sesman[27]: [INFO ] Terminal Server Users group is disabled, allowing authentication
xrdp[30]: [DEBUG] xrdp_wm_login_mode_changed: login_mode is 3
xrdp-sesman[27]: [INFO ] ++ created session (access granted): username ubuntu, ip 134.249.100.224:39088 - socket: 11
xrdp-sesman[27]: [INFO ] starting Xorg session...
xrdp-sesman[27]: [INFO ] Starting session: session_pid 32, display :10.0, width 1280, height 960, bpp 24, client ip 134.249.100.224:39088 - socket: 11, user name ubuntu
xrdp-sesman[32]: [INFO ] [session start] (display 10): calling auth_start_session from pid 32
xrdp-sesman[27]: [ERROR] sesman_data_in: scp_process_msg failed
xrdp[30]: [INFO ] xrdp_wm_log_msg: login successful for display 10
xrdp-sesman[32]: pam_systemd(xrdp-sesman:session): Failed to connect to system bus: No such file or directory
xrdp-sesman[32]: pam_unix(xrdp-sesman:session): session opened for user ubuntu(uid=1020) by (uid=0)
xrdp[30]: [INFO ] login successful for display 10
xrdp-sesman[27]: [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
xrdp[30]: [INFO ] loaded module 'libxup.so' ok, interface size 10296, version 4
xrdp[30]: [DEBUG] xrdp_wm_log_msg: started connecting
xrdp[30]: [INFO ] started connecting
xrdp[30]: [INFO ] lib_mod_connect: connecting via UNIX socket
xrdp[30]: [INFO ] lib_mod_log_peer: xrdp_pid=30 connected to X11rdp_pid=34 X11rdp_uid=1020 X11rdp_gid=1020 client_ip=... client_port=39088
xrdp[30]: [DEBUG] xrdp_wm_log_msg: connected ok
xrdp[30]: [INFO ] connected ok
xrdp[30]: [DEBUG] Login state change request WMLS_CONNECT_IN_PROGRESS -> WMLS_CLEANUP
xrdp-sesman[33]: [INFO ] Found X server running at /tmp/.X11-unix/X10
xrdp-sesman[32]: [INFO ] Found X server running at /tmp/.X11-unix/X10
xrdp-sesman[32]: [INFO ] Session started successfully for user ubuntu on display 10
xrdp-sesman[67]: [INFO ] Starting the xrdp channel server for display 10
xrdp-sesman[32]: [INFO ] Session in progress on display 10, waiting until the window manager (pid 33) exits to end the session
xrdp[30]: [DEBUG] libxrdp_query_channel - Channel 0 name cliprdr
xrdp[30]: [DEBUG] libxrdp_query_channel - Channel 1 name drdynvc
xrdp[30]: [DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
xrdp[30]: [DEBUG] Closed socket 23 (AF_INET 127.0.0.1:40462)
xrdp[30]: [DEBUG] xrdp_wm_login_mode_changed: login_mode is 4
xrdp[30]: [DEBUG] Login state change request WMLS_CLEANUP -> WMLS_INACTIVE
xrdp[30]: [DEBUG] xrdp_wm_login_mode_changed: login_mode is 5
xrdp[30]: [ERROR] Fastpath frame acks is disabled
xrdp[30]: [DEBUG] compress_rdp failed, sending uncompressed data. type 2, flags 1
skochko commented 3 years ago

Everything worked, thanks, the issue can be closed. Unfortunately, the error remains

xrdp[30]: [ERROR] Fastpath frame acks is disabled
xrdp[30]: [DEBUG] compress_rdp failed, sending uncompressed data. type 2, flags 1
matt335672 commented 3 years ago

The 'Fastpath frame acks is disabled' is occurring because the client is not sending a particular message to us, that message being a CAPSSETTYPE_FRAME_ACKNOWLEDGE PDU.

We don't request that message, so there must be something in your client settings that's causing it not to be sent. As mstsc.exe is closed source, it's not really simple to work out what that could be. All I can suggest is checking you're selecting a colour depth of 32 and playing around with the performance settings.

Hope that's a bit useful.

hardening commented 3 years ago

From what I'm seeing in the specs, TS_FRAME_ACKNOWLEDGE_CAPABILITYSET only gives a hint of how many inflight frames the client supports. Perhaps the server should have a sane default value. Probably that mstsc does not send that capability set, while claiming that it support remoteFx as a way of telling "I can remoteFX, but it's not my preferred codec". I've not looked, but is Xrdp checking that the client do support the remoteFx codec ?

matt335672 commented 3 years ago

That's a very good question.

From what I can see (and this isn't really an area I'm familiar with), xrdp is processing the TS_RFX_CAPS structure here. I'd expect a log message to be generated at this point. @skochko doesn't mention this message, and I'm not seeing it in my logs either. So it seems likely the client doesn't support RFX.

This post from @speidy may be significant here. As I say, it's not an area I'm familiar with.