My team currently runs a custom version of the guacamole server based off of
version 0.9.9. We recently merged in commits from
GUACAMOLE-40<https://issues.apache.org/jira/browse/GUACAMOLE-40> to get support
RDS. We specifically cherry picked from these commits made on Apr 10 2017:
https://github.com/glyptodon/guacamole-server/commit/af8ef9f526546acc6682cb8ea591f7dad7f849d8
https://github.com/glyptodon/guacamole-server/commit/da8636ef546add9f71db6ffcc0d873e085d5e13f
https://github.com/glyptodon/guacamole-server/commit/09099050cb2448a6b40ac3b17eab59f47c57d6a2
We only took the changes specifically for the load-balance-info switch and
didn’t not take the gateway or C MACRO changes.
We are running on CentOS 7 with a compiled version of FreeRDP branch stable-1.1.
The issue that we have is that while using the /load-balance-info switch on
xfreerdp we see the connection work and opens the appropriate VDI session.
However, when we use the same switch within GUACD we never return from the
connect phase.
/* Connect to RDP server */
if (!freerdp_connect(rdp_inst)) {
guac_client_abort(client, GUAC_PROTOCOL_STATUS_UPSTREAM_ERROR, "Error
connecting to RDP server");
return 1;
}
The execution never returns to here. With a printf inside the if and below the
if, neither are activated.
From debugging freerdp we see the redirection PDU returned on the main process
loop (connection.c:: rdp_client_connect) and the process switches over to the
redirection code branch and starts another loop. The redirection loop
eventually gets all the way through the rdp-state values to
CONNECTION_STATE_FINALIZATION and rdp-state is changed to
CONNECTION_STATE_ACTIVE. This is all successful. The redirection loop exists.
And then the execution disappears. It is not returned up through the main loop.
The process flow as I have traced it is:
freerdp.c freerdp_connect (main entry point)
connection.c rdp_client_connect (while ! active) - never see this loop exit,
the thread/process just goes away.
rdp.c rdp_check_fds
transport.c transport_check_fds (transport->ReceiveCallback)
rdp.c rdp_recv_callback (switch on rdp->state)
when rdp->state == CONNECTION_STATE_CAPABILITY
connection.c rdp_client_connect_demand_active
rdp.c rdp_recv_out_of_sequence_pdu
redirection.c rdp_recv_enhanced_security_redirection_packet
redirection.c rdp_recv_server_redirection_pdu
connection.c rdp_client_redirect
connection.c rdp_client_connect (while ! active) - this inner loop will exit
dp.c rdp_check_fds
transport.c transport_check_fds (transport->ReceiveCallback)
rdp.c rdp_recv_callback (switch on rdp->state) - waiting for
CONNECTION_STATE_FINALIZATION
I added some debug statements to the FreeRDP code to help visualize the
execution path (been in the Java world for that last 15 years so I’m struggling
with getting GDB to hit a breakpoint)
*** 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’m just curious if this something that had come up during the development or
testing of GUACAMOLE-40.
Again, we did not merge the gateway changes. Only the broker/load-balance-info
changes. I’m not passing any gateway info to xfreerdp either.
xfreerdp /load-balance-info:tsv://VMResource.1.win8_test_1 /u:testuser1
/v:10.1.11.3 /cert-ignore
but maybe the X client initializes some gateway settings different than GUAC???
Any advice or thoughts would be appreciated.
Thanks,
Kris Keller
