sesman not reusing existing (matching) Xvnc

Hi,

I downloaded and built xrdp 0.5.0 on CentOS 5.3.  I am able to use Remote Desktop Connection on both Windows XP Pro x64 and Windows 7 Pro x64.  The speed improvement over remote connection is beneficial.  I am able to authenticate against LDAP after modifying xrdp-sesman as found in users' notes.

I do have one issue ;).  Each Remote Desktop Connection session creates a new instance of Xvnc.  I do see matching Xvnc parameters in my process listing.

# ps -elf | grep -i xvnc
0 S qms000    4329     1  0  75   0 - 19900 -      Jan05 ?        00:06:34 Xvnc :1 -desktop tx14-dig-linux8.ftw.mot.com:1 (qms000) -httpd /usr/share/vnc/classes -auth /home/qms000/.Xauthority -geometry 1680x1050 -depth 16 -rfbwait 30000 -rfbauth /home/qms000/.vnc/passwd -rfbport 5901 -pn
4 S qms000   25476 25474  0  75   0 - 14232 -      Jan09 pts/13   00:00:00 Xvnc :10 -geometry 1920x1200 -depth 16 -rfbauth /home/qms000/.vnc/sesman_qms000_passwd -bs -ac -nolisten tcp
4 S qms000   25605 25603  0  75   0 - 14231 -      Jan09 pts/13   00:00:00 Xvnc :11 -geometry 1920x1200 -depth 16 -rfbauth /home/qms000/.vnc/sesman_qms000_passwd -bs -ac -nolisten tcp
4 S qms000   25731 25729  0  75   0 - 14409 -      Jan09 pts/13   00:00:01 Xvnc :12 -geometry 1920x1200 -depth 16 -rfbauth /home/qms000/.vnc/sesman_qms000_passwd -bs -ac -nolisten tcp
4 S qms000   26599 26597  0  75   0 - 19804 -      Jan09 pts/13   00:00:03 Xvnc :13 -geometry 1920x1200 -depth 24 -rfbauth /home/qms000/.vnc/sesman_qms000_passwd -bs -ac -nolisten tcp
4 S qms000   28010 28008  0  75   0 - 21462 -      00:18 pts/13   00:00:14 Xvnc :14 -geometry 1920x1200 -depth 24 -rfbauth /home/qms000/.vnc/sesman_qms000_passwd -bs -ac -nolisten tcp
0 S root     28320 28143  0  78   0 - 15301 pipe_w 00:47 pts/22   00:00:00 grep -i xvnc

Any pointers?  It would be nice to get the same desktop when connecting from a different computer / location working.

Thanks,
-jboxx

Hi,

I added some debug code which may allow someone to help with my configuration.  I print out the existing sessions in the session_get_bydata() function.  It looks like the session type is originally 0 at scp_v0_process().  The session type, however ,is 2 once the Xrdp->Xvnc session is created.  I am going to 'hack' the initial check for now …

  listening…
  scp thread on sck 7 started successfully
  scp_v0_process( );
  session_get_bydata( ); username=qms000 width=1920 height=1200 bpp=16 type=0
  walking through existing sessions:
  existing session NOT found
  granted TS access to user qms000
  starting Xvnc session…
  session_sync_start( );
  session_start_fork( ); width=1920 height=1200 bpp=16 username=qms000
  SESMAN_SESSION_TYPE_XVNC
  starting xrdp-sessvc - xpid=19907 - wmpid=19906

  scp thread on sck 7 started successfully
  scp_v0_process( );
  session_get_bydata( ); username=qms000 width=1920 height=1200 bpp=16 type=0 <- ***
  walking through existing sessions:
    name=qms000 width=1920 height=1200 bpp=16 type=2 <- ***
  existing session NOT found
  granted TS access to user qms000
  starting Xvnc session…
  session_sync_start( );
  session_start_fork( ); width=1920 height=1200 bpp=16 username=qms000
  SESMAN_SESSION_TYPE_XVNC
  starting xrdp-sessvc - xpid=20035 - wmpid=20034

Thanks!
-jboxx

I think that this problem is due to the existing session test (session_get_bydata).
In particular, this function test the session type which pass to SCP_SESSION_TYPE_MANAGE after the first session launch

Great research jboxx! Here's my horrible hack that works for me, in case anyone else was wondering. :)

--- xrdp.orig/sesman/session.c  2009-12-27 10:02:56.000000000 +1100
+++ xrdp/sesman/session.c   2010-02-02 18:40:28.960556248 +1100
@@ -55,6 +55,10 @@ session_get_bydata(char* name, int width
 {
   struct session_chain* tmp;

+  // Hack, as suggested at:
+  // https://sourceforge.net/projects/xrdp/forums/forum/389417/topic/3513019
+  type = 2;
+
   /*THREAD-FIX require chain lock */
   lock_chain_acquire();

I should note that this hack only allows a session to be resumed if the client requests the exact same resolution and color depth. If these parameters differ when the client tries to resume, they will get a new session instead.

I got stuck for a few minutes trying to resume a session on one older machine where the X server could apparently only display 16. According to the rdesktop man page, "The default value is the depth of the root window." and hence this value changed from system to system while still using the same rdesktop command with a specified resolution.

Thanks guys !

Hello,

I believe I am having a similar issue not sure.... There isnt any information in my log files that show me what is the cause. I have an opensuse 13.2 VM with xrdp 'xrdp-v0.6.1' and it works just fine. I got authenticating against my domain controller everything works I can log in once.

If I close my session by hitting the red 'X' I can reconnect to my session. If I actually choose log out from the desktop session. I am no longer able to reconnect using that user. Unless i change the resolution to a lower setting/resetart the xrdp service.

Also once user uses a different resolution setting and attempt to log back in, if you've logged out from the desktop vs hitting red 'X'. Same thing happens can no longer log in, unless I restart the service.

Can anyone tell me how I can fix this?

Please and thank you