>
> >
> Looks reasonable. Naming convention within libguac for the various
> instruction sending functions is guac_protocol_send_OPCODE(), though, so
> this would need to be guac_protocol_send_required().
>
I've updated the naming conventions on these...
>
> Perhaps the instruction should accept a list of parameter names rather than
> just a single name? This is what is done for the related "args"
> instruction:
>
> https://guacamole.apache.org/doc/1.0.0/libguac/protocol_8h.html#a6047d380b097ebc7d5f35b167e3419e6
>
>
Yeah, this was my next step, but just thought I should start with getting
it working, then move on to making the code more efficient.
> Client:
> >
> >
> https://github.com/necouchman/guacamole-client/commit/72de5595880baea46505cf4f9ad49640f16519e7
>
>
> Same here - convention is "onOPCODE", so this would need to be
> "onrequired".
>
Fixed.
> >
> I think you will run into trouble manually parsing the Guacamole protocol
> with a guac_parser in a context where inbound instructions are already
> being parsed received. Is this because the FreeRDP authentication callback
> must be synchronous?
>
>
I'm not sure. On the xfreerdp side of things, this code results in a
Password: prompt on the command line, and the xfreerdp app waits until you
enter something before proceeding.
The piece that sends back the requests for information to the client
appears to be working, it's the whole stopping and waiting piece that isn't
quite there. In particular, with my debugging code, on the client-side I
get the following message:
>>>PROMPT<<< Selected the following field: {
"name": "username",
"type": "USERNAME"
}
So, it's seeing the need for a username and sending it back to the client.
Unfortunately, for whatever reason, it doesn't actually wait for the client
to respond - I just immediately get the message:
> The remote desktop server is currently unreachable. If the problem
persists, please notify your system administrator, or check your system
logs.
with the reconnect in 15 seconds dialog, and the option to go home, etc.
> Things will need to be changed to allow normal handling of received
> instructions, with the response to your prompt being received via two argv
> streams, handled with user->argv_handler, etc. This may already be doable
> if the FreeRDP aspects of the connection are in a separate thread (I think
> they are), as this function could (1) send the request for credentials and
> (2) block on a pthread conditional waiting for those credentials to be
> received.
>
Ah, okay, is there anything special to do to block the pthread?
>
> What error are you seeing specifically?
>
>
On the client-side I get the message I posted above - the server is
unreachable, reconnecting, etc. On the server-side, I get the following:
Mar 13 13:15:16 guachost1 guacd[51397]: User
"@75e645b0-6d05-454d-bbdc-e95a772009b6" joined connection
"$93d136f6-c210-443f-aa78-2fd1b92a9832" (1 users now present)
Mar 13 13:15:16 guachost1 guacd[51397]: Loading keymap "base"
Mar 13 13:15:16 guachost1 guacd[51397]: Loading keymap "en-us-qwerty"
Mar 13 13:15:16 guachost1 guacd[51397]: Unable to get username from client.
Mar 13 13:15:16 guachost1 guacd[51397]: Error connecting to RDP server
Mar 13 13:15:16 guachost1 guacd[51397]: User
"@75e645b0-6d05-454d-bbdc-e95a772009b6" disconnected (0 users remain)
Mar 13 13:15:16 guachost1 guacd[51397]: Last user of connection
"$93d136f6-c210-443f-aa78-2fd1b92a9832" disconnected
Mar 13 13:15:16 guachost1 guacd[51397]: Requesting termination of client...
Mar 13 13:15:16 guachost1 guacd[51397]: Client terminated successfully.
Mar 13 13:15:16 guachost1 guacd[46005]: Connection
"$93d136f6-c210-443f-aa78-2fd1b92a9832" removed.
So, you're probably right - it's probably either not blocking, or the other
protocol messages going back-and-forth during this time are triggering it
to continue, and it continues not having received the information it was
expecting??
-Nick
