You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@guacamole.apache.org by Kris Keller <kr...@overwatchid.com> on 2018/01/23 20:33:57 UTC
RDS Broker (load balance) support
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
Re: RDS Broker (load balance) support
Posted by Kris Keller <kr...@overwatchid.com>.
Thanks Mike. I’ll build from master and see what I get. Sorry for referencing those commits from the wrong repo. They are the same commits across both.
On 1/23/18, 3:08 PM, "Mike Jumper" <mi...@guac-dev.org> wrote:
On Tue, Jan 23, 2018 at 12:33 PM, Kris Keller <kr...@overwatchid.com>
wrote:
> 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
>
>
Beware that this is not the upstream git repository for guacamole-server;
it is the repository used by the project prior to the move to the ASF. The
correct repository for guacamole-server is:
https://github.com/apache/guacamole-server
We only took the changes specifically for the load-balance-info switch and
> didn’t not take the gateway or C MACRO changes.
>
A forked, modified version of 0.9.9 with some upstream commits backported /
cherry-picked is simply not an Apache Guacamole release. Before moving
forward with this, can you please try to reproduce what you're seeing
against the latest upstream code (either 0.9.14 or git master)? The
conversation and investigation for this really needs to be relevant to
Apache Guacamole and its community, rather than to your internal fork.
If this is determined to be a bug, the issue is fixed upstream, and you
ultimately backport that fix to your internal fork, that's absolutely fine,
but the baseline for everything here needs to be current, unmodified,
Apache Guacamole.
- Mike
Re: RDS Broker (load balance) support
Posted by Mike Jumper <mi...@guac-dev.org>.
On Tue, Jan 23, 2018 at 12:33 PM, Kris Keller <kr...@overwatchid.com>
wrote:
> 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
>
>
Beware that this is not the upstream git repository for guacamole-server;
it is the repository used by the project prior to the move to the ASF. The
correct repository for guacamole-server is:
https://github.com/apache/guacamole-server
We only took the changes specifically for the load-balance-info switch and
> didn’t not take the gateway or C MACRO changes.
>
A forked, modified version of 0.9.9 with some upstream commits backported /
cherry-picked is simply not an Apache Guacamole release. Before moving
forward with this, can you please try to reproduce what you're seeing
against the latest upstream code (either 0.9.14 or git master)? The
conversation and investigation for this really needs to be relevant to
Apache Guacamole and its community, rather than to your internal fork.
If this is determined to be a bug, the issue is fixed upstream, and you
ultimately backport that fix to your internal fork, that's absolutely fine,
but the baseline for everything here needs to be current, unmodified,
Apache Guacamole.
- Mike