[RemoteDesktop]: after closing a connection, can't reconnect to the server

[ttcoder]

Tried running ./RemoteDesktop --listenOnly on computer A and ./RemoteDesktop user@192.168.1.13 -c /boot/system/apps/StyledEdit on machine B but nothing happens; the mouse cursor is not visible, and the window/remote-view remains white on both computers.

Adding a few printf()s to the code I have the impression that no network traffic is occuring, but I didn't dig deep.

[pulkomandy]

You don't need to run RemoteDesktop on the remote side (A), only make sure an ssh server is running.

Make sure A is not already running StyledEdit, because it's currently not possible to have the same app running both local and remote.

I have written a short guide on how to use it: ​http://www.haiku-os.org/node/6007

[ttcoder]

There seems to be a problem with ssh:

~/Desktop> ps | grep sshd
~/Desktop> sshd
sshd re-exec requires execution with an absolute path
~/Desktop> /boot/system/bin/sshd -D
Privilege separation user sshd does not exist
~/Desktop> uname -a
Haiku shredder 1 hrev47395 Jun 17 2014 00:28:46 BePC x86 Haiku
~/Desktop> cat /boot/system/settings/network/services
#service telnet {
#       launch  telnetd
#}

#service ftp {
#       launch  ftpd
#}

service ssh {
        launch  /boot/system/bin/sshd -D
        stand_alone
}

I'm new to this so might be missing something obvious..

Also there are references to /boot/common in the settings files, but they also reference /boot/system as well so that might not be the reason for the problem..

# This sshd was compiled with PATH=.:/boot/home/config/non-packaged/bin:/boot/home/config/bin:/boot/common/non-packaged/bin:/boot/common/bin:/bin:/boot/common/apps:/boot/common/preferences:/boot/system/apps:/boot/system/preferences

[pulkomandy]

You need to create the sshd user to enable sshd:

useradd sshd

The server will be started automatically at next boot, or you can run it manually.

You also need to set a password for the default user:

passwd

RemoteDesktop will then request this password when connecting. If you don't want to type a password, an ssh key pair can also be used. The remaining references to common in sshd are not a problem, but we should still clean them up.

[ttcoder]

It works! Please close ticket as invalid, and thanks for helping me out on this :-)

Maybe the URL to your article could be mentionned in the source files, as that's the first place guys like me go to, when in search of information; just an idea..

​http://www.haiku-os.org/node/6007

I'll post further comments to the article itself I think as it's more appropriate. In terms of comments, I mean e.g. -- If I had time to work on it, one of the first things I'd do would be to 'fix' the Alt-W shortcut being handled locally (it closes down RemoteDesktop) instead of closing the applications launched remotely; also if closing down RemoteDesktop, it won't be able to connect back again, until the 'server' machine is rebooted. I'm going to explore more (and I gotta remember to NOT hit Alt-W, damn it :-b)

[ttcoder]

Something that looks like a bug, thus "ticket material":

Even if I quit the client cleanly, the server still keeps its bash session... Maybe that is why further attempts to connect to it all fail until I reboot ?

~/Desktop> ps
Team                                                  Id #Threads  Gid  Uid 
(..)
/bin/bash -c echo connected; export TARGET_SCREEN=localhost:109  1619        1    0    0 
/boot/system/apps/Terminal                          1620        5    0    0 
/bin/bash -l                                        1625        1    0    0 
/boot/system/apps/Terminal                          1702        5    0    0 
/bin/bash -l                                        1707        1    0    0 
/bin/ps                                             1725        1    0    0 
~/Desktop> 

EDIT: even if I kill all the above processes by hand, a reboot is still needed before the client can connect again... There must be another issue at play here.

EDIT2: storing a few findings here for me to pick up later when time permits..:

• app_server wise, the remote desktop is seemingly served like an additional (hardware) screen, instantiated ​here. Edit3: its seems that AppServer::_DispatchMessage() receives AS_GET_DESKTOP (how??); which calls AppServer::_CreateDesktop(); which calls Desktop::Desktop(); which calls VirtualScreen::SetConfiguration(); which eventually calls ScreenManager::AcquireScreens() -- which in turn instantiates an RDesktop handler, opening a listener port ..etc.
• it's possible the 'RemoteHWInterface' screen is invoked through an incoming sshd connection being forwarded to the app_server(?). I don't understand how/when the 'HTML5HWInterface' is supposed to be instantiated, and couldn't make it occur here.
• it seems applications tell app_server what "screen" they want to be displayed on ​here, passing $TARGET_SCREEN to app_server: since they are run from the same Terminal session that was opened by the initial connection, and sub-processes/apps inherit the environment variables of their parent Terminal, all apps launched from there will be displayed on the remote desktop/screen instead of the main screen.

So the server-side sequence looks like this:

• sshd executes the "TARGET_SCREEN=localhost:10900; Terminal" ... line
• Terminal launches, going through ​BApplication::_ConnectToServer()
• create_desktop_connection() ​sends the target screen to app_server
• app_server opens port 10900 (by instantiating class RemoteHWInterface)
• ..etc

EDIT: regarding the mention of #11836 by Augustin below, seems Michael was wondering about the same thing when he wrote the code: ​http://cgit.haiku-os.org/haiku/tree/src/servers/app/drawing/interface/remote/NetReceiver.cpp#n46

// TODO: find out why closing the endpoint doesn't notify the waiter

[pulkomandy]

HTML5HWInterface is unrelated to RemoteDesktop, and is used with a client page which does the drawing on a javascript canvas, rather than the ssh+BWindow used by RemoteDesktop.

Renaming the ticket to reflect current state of things.

[waddlesplash]

I wonder if this is somehow related to #11836?

[waddlesplash]

This is probably fixed following the change to reverse the connection direction. Please retest.