On Wed, Sep 2, 2020 at 10:00 AM erez <[email protected]> wrote: > Hey Nick, thanks for the fast answer. > Currently, we are not using any reverse proxies in front of the tomcat. The > requests from the client are headed directly to the tomcat server. > > About the firewalls, the guacd is running on an Ubuntu machine on AWS. The > guac port is open. I think nothing should disrupt communications. > > Can you please elaborate more on these exceptions? Why are they happening? > When? This information can lead me to the solution. > > > Are you using a custom Guacamole application, or the official Guacamole Client application?
I can elaborate a little more on the exceptions, but the reason that I asked for more information is because more information is required to figure out exactly why they're happening. The small bit of code you posted provides no context to where that code is - it *looks* to me like it is Java code, so somewhere in the Java application, but it also could possibly be JavaScript or even C. I cannot even determine the language being used from either the "code" posted or the small summary you gave of the exception. So, far more detail about the environment, the code, etc., is required to fully debug the issue. The exceptions you're getting, "Non-numeric character in element length," and "Element terminator of instruction was not ';' nor ','", seem to indicate that the Guacamole protocol is getting messed up somewhere along the way. The way Guacamole works, the very first part of any instruction should be a number indicating the length of the instruction to follow, then the instruction itself, and then either a comma or a semicolon. You can see this if you look at the protocol code - for example: https://github.com/apache/guacamole-server/blob/382d72a26a04008aa936680deed00e3a31086b1e/src/libguac/protocol.c#L71-L87 You see that sending the "ack" instruction starts with a "3.ack," - 3 being the number of characters to expect, a dot, and then the instruction, then a comma and the next piece of the instruction. It seems likely that the exceptions you're seeing are because the system is receiving something other than a number as the very first part of an instruction, when it should be a number, or is not properly terminated with either a comma or semicolon. The possible causes of this that I can think of are: * Incorrectly written custom code that does not set up protocol instructions correctly with a number as the start of the code. This is why I asked if you're using a custom Guacamole application (there's nothing wrong with this, it just leads in a certain direction in terms of debugging) or if you're using the stock code (the full Guacamole Client). If you're using stock code, the likelihood that it's a bug in that code causing this is extremely small, as it's very basic to the functionality of the application and something we'd likely be getting broad reports about. * Improperly written custom code that does not flush the socket when it's done with a stream of instructions. I've encountered this a few times when working on support for parameter prompting - that prompts either didn't get delivered, or got half-delivered, resulting in exceptions similar to what you're seeing, because I wasn't flushing the socket when I was expecting that to be the end of one side of the communication. * A firewall (or virus scanner, etc.) in between the client and the server that is interfering with the conversation. It could be stripping out data that it considers harmful or trying to compress/streamline data that could cause changes in the protocol data being transmitted between client and server. This is why I asked about Web Application Firewalls and the like - if those can be investigated/eliminated to make sure there's nothing that is trying to secure Guacamole that might actually be causing problems. * An improperly configured reverse proxy server that is buffering data. In the instructions for configuring Guacamole behind a proxy we specifically mention turning off buffering, as it necessarily results in "bursty" communication where you actually want a steady stream of data, and that could potentially cause exceptions similar to the ones you're seeing. So, you're welcome to take this information and go looking for the cause of the problem, and you're also welcome to post back here and get further help resolving it. If you choose to post back here I highly suggest you provide *detailed* information on the exceptions you're seeing (log messages), the environment you're running, the code you're using, the context of the code and the exceptions, etc. -Nick
