[
https://issues.apache.org/jira/browse/GUACAMOLE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16337755#comment-16337755
]
Kris Keller commented on GUACAMOLE-370:
---------------------------------------
There are two types of connections established through the use of the
load-balance-info switch/parameter.
[https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc725560(v=ws.11)]
* Session Host
* Virtualization Host
Session Host has a load-balance-info value similar to "tsv://MS Terminal
Services Plugin.1.RDS-SD-Test". This approach works and Guac/FreeRDP behave
very similar to just specifying the hostname directly and bypassing the broker.
Virtualization Host has a load-balance-info with the format of
"tsv://VMResource.1.win8_test_1". This is the scenario that does NOT work.
I have not tried to use the docker container. I have only tried against a
compiled version of 0.9.14 (off of master 21-Jan_2018). I'm also using a self
compiled version of FreeRDP from the stable-1.1 branch on CentOS 7.
when i use the same switch directly agains the xfreerdp client, it works.
xfreerdp /load-balance-info:tsv://VMResource.1.win8_test_1 /u:testuser1
/v:10.1.11.3 /cert-ignore
The above command will launch a new window displaying the correct virtualized
host.
In attempting to debug, i notice that process execution never returns to this
point in src/protocols/rdp.c
{code:java}
/* Connect to RDP server */
if (!freerdp_connect(rdp_inst)) {
//NEVER RETURNS HERE
guac_client_abort(client, GUAC_PROTOCOL_STATUS_UPSTREAM_NOT_FOUND,
"Error connecting to RDP server");
return 1;
}
//AND NEVER RETURNS HERE{code}
its been very difficult to debug the process using GDB because of multiple
processes and threads and the fact that the sockets/threads timeout before you
can get to the code to debug (at least in my "the force is weak" world). So i
reverted to the good ole printf approach :(
My output is as follow:
*** freerdp: before connect ***
User: t Domain: o Password: 1
1739598272 Entering loop with usage 0 (i added the usage code so new if i
was in the main loop or redirect loop)
1739598272 CONNECTION_STATE_NEGO
1739598272 CONNECTION_STATE_MCS_ATTACHE_USER
1739598272 CONNECTION_STATE_MCS_CHANNEL_JOIN
1739598272 CONNECTION_STATE_MCS_CHANNEL_JOIN
1739598272 CONNECTION_STATE_MCS_CHANNEL_JOIN
1739598272 CONNECTION_STATE_MCS_CHANNEL_JOIN
1739598272 CONNECTION_STATE_MCS_CHANNEL_JOIN
1739598272 CONNECTION_STATE_MCS_CHANNEL_JOIN
1739598272 CONNECTION_STATE_LICENSE
1739598272 CONNECTION_STATE_LICENSE
1739598272 CONNECTION_STATE_LICENSE
1739598272 CONNECTION_STATE_CAPABILITY
*** connections.c:rdp_client_connect_demand_active before out_of_sequence
***
1739598272 rdp.c rdp_recv_out_of_sequence before
rdp_recv_enhanced_security_redirection ***
*** redirection.c before rdp_client_redirect ***
*** connection.c: rdp_client_redirect before rdp_client_connect ***
User: T Domain: O Password: 1
1739598272 Entering loop with usage 1 (usage 1 is the redirection loop)
1739598272 CONNECTION_STATE_NEGO
1739598272 CONNECTION_STATE_MCS_ATTACHE_USER
1739598272 CONNECTION_STATE_MCS_CHANNEL_JOIN
1739598272 CONNECTION_STATE_MCS_CHANNEL_JOIN
1739598272 CONNECTION_STATE_MCS_CHANNEL_JOIN
1739598272 CONNECTION_STATE_LICENSE
1739598272 CONNECTION_STATE_CAPABILITY
1739598272 CONNECTION_STATE_CAPABILITY success
1739598272 CONNECTION_STATE_FINALIZATION
1739598272 CONNECTION_STATE_FINALIZATION status=0
1739598272 CONNECTION_STATE_FINALIZATION pdu=1
1739598272 CONNECTION_STATE_FINALIZATION
1739598272 CONNECTION_STATE_FINALIZATION status=0
1739598272 CONNECTION_STATE_FINALIZATION pdu=3
1739598272 CONNECTION_STATE_FINALIZATION
1739598272 CONNECTION_STATE_FINALIZATION status=0
1739598272 CONNECTION_STATE_FINALIZATION pdu=7
1739598272 CONNECTION_STATE_FINALIZATION
1739598272 CONNECTION_STATE_FINALIZATION status=0
1739598272 CONNECTION_STATE_FINALIZATION pdu=15
1739598272 CONNECTION_STATE_FINALIZATION setting state to ACTIVE ***
********** Exiting loop with usage 1
*** connection.c: rdp_client_redirect after rdp_client_connect ***
*** redirection.c after rdp_client_redirect 1 ***
1739598272 rdp.c rdp_recv_out_of_sequence after
rdp_recv_enhanced_security_redirection 1 ***
*** connections.c:rdp_client_connect_demand_active after out_of_sequence
success ***
1739598272 CONNECTION_STATE_CAPABILITY success
********** revc_status from ReceiveCallback 0
After this the thread just stops. I can find no place that it exits or
terminates. The process is running and listening for new connections but the
old connection request is done.
If I excute the same connection with XFreeRDP directly then the output
continues with
********** Exiting loop with usage 0
*** freerdp: after connect
****** freerdp: before extension_post_connect
****** freerdp: after extension_post_connect
****** freerdp: before PostConnect(guac)
****** freerdp: after PostConnect(guac)
***transport: fast path header is available
transport: read fast path header
1845974784 CONNECTION_STATE_ACTIVE
I find that the execution path is as follows within FreeRDP:
{code:java}
V freerdp.c freerdp_connect (main entry point) X
V connection.c rdp_client_connect (while ! active) - never see this loop exit,
the thread/process just goes away. X
V rdp.c rdp_check_fds X
V transport.c transport_check_fds (transport->ReceiveCallback) ^
V rdp.c rdp_recv_callback (switch on rdp->state) ^
V when rdp->state == CONNECTION_STATE_CAPABILITY ^
V connection.c rdp_client_connect_demand_active ^
V rdp.c rdp_recv_out_of_sequence_pdu ^
V redirection.c rdp_recv_enhanced_security_redirection_packet ^
V redirection.c rdp_recv_server_redirection_pdu ^
V connection.c rdp_client_redirect ^
V connection.c rdp_client_connect (while ! active) - this inner loop will exit ^
V dp.c rdp_check_fds ^
V transport.c transport_check_fds (transport->ReceiveCallback) ^
V rdp.c rdp_recv_callback (switch on rdp->state) - waiting for
CONNECTION_STATE_FINALIZATION ^
{code}
V = Down the rabbit hole
^ = Up the rabbit hole
X = Black hole
Yes, all that is traced within FreeRDP. But keep in mind, that the XFreeRDP
client is working with the same switch. So is there something different
between XFreeRDP and GUACD? Different initialization?
I have no idea how a thread can go down a rabbit hole and never come out unless
there is a SIGSEGV but GDB never shows that. I don't know if i have to be
actively debugging that thread when it occurs to see it or not.
Anyways, any help would be appreciated. I'll continue to debug myself as well
as try the docker image.
> Missing broker support in RDP
> -----------------------------
>
> Key: GUACAMOLE-370
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-370
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
> Affects Versions: 0.9.13-incubating
> Environment: Ubuntu Xenial 16.04
> Reporter: Rodrigo Gonçalves
> Priority: Major
>
> Connecting to a broker does not work. _load-balancing-info_ informed as well
> but no success.
> Only "Error connecting to RDP server" in guacd logs.
> When trying to connect to one of the serves in the collection, it will work
> if it is the server running the user session.
> If a connection is tried to a secondary server, and this tries to redirect to
> the correct one, the connection is lost in guacd.
> Config used:
> {code:xml}
> <config name="Desktop Virtual" protocol="rdp">
> <param name="hostname" value="broker-address" />
> <param name="port" value="3389" />
> <param name="enable-printing" value="true" />
> <param name="ignore-cert" value="true" />
> <param name="load-balancing-info" value="tsv://MS Terminal Services
> Plugin.1.Secretarias" />
> </config>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
