On Wed, Dec 16, 2020 at 12:46 PM Pietro <[email protected]> wrote:
> Hi Nick, > > Honestly we are not convinced the issue is on the network. The 4G > connection > we experienced the issue with is fast and it is used daily with no issues > or > slowdowns. It is used for conference calls and with various remote desktop > protocols (VNC, RDP) and clients (noVNC, xfreerdp and rdesktop) with no > issues. We would like to use Guacamole with it as well. > > Whether the network is performing well or not does not necessarily indicate whether they're doing something to the traffic that could adversely impact the way in which Guacamole works. I'm not saying it's definitely the network, but, if that's the only network on which you experience problems, and other networks (like a different 4G network or WiFi) work fine, then I suspect it's something somehow related to the network. I'm just looking for common issues that point in one direction or another. > Do the logs we sent you suggest that there might be problems in the > guacamole code/protocol? > No, the logs you've provided are not indicative of any problems in the code or protocol. Furthermore, again, the fact that it works fine on some networks (including other 4G networks), and that there are not many other users on the mailing list reporting these types of issues makes me less inclined to believe there's a bug in the code. The logs you sent indicate that guacd is not receiving the messages it expects from the client in the timeframe it expects them. This could be an issue with Tomcat or something else on the server, but it also could be an issue where the messages from the client are getting dropped somewhere along the way. Based on the information you've provided, I lean toward the later, but, again, it's just my guess. > In particular if you check the events timing and their correlation with the > components involved in the chain (e.g. browser-side and Tomcat-side) you > should notice that "strange" things happen. > > Based on the log messages you provided, what I see is: - guacd stops receiving messages from the client, for some, as yet unknown, reason. - After a timeout period, guacd shuts down the connection, assuming that the user is no longer there. - Tomcat complains about the fact that the connection to guacd has been terminated unexpectedly. The only thing "strange" about this is why guacd stops receiving messages from the client, which is what needs to be investigated. The rest of the messages seem pretty normal to me. > We are evaluating the use of Guacamole in an environment where there might > be up to 25 concurrent users connected to the same RDP target (or VM). > Users > are spread all over the Europe and access through various networks, from > here our concerns. > > Sure, understand the concern and the need to get it working correctly, and we're happy to help you work through the issues. But, I'm not seeing any signs of a bug in the code or protocol at this point. You might have to do some network packet captures to see if the traffic is making it all the way through - that is, if you capture the packets between the Browser and Reverse Proxy, then between Tomcat and guacd, do you see all of the traffic that you expect to see, or are things dropping along the way. Note that, because you're doing a reverse proxy and (likely) encrypting it, you won't be able to see the contents of the packets themselves, but you should at least be able to see the number of packages and relative size and correlate it to what is getting sent on to guacd. It won't be a 1-to-1 correlation (not every packet to Tomcat should be sent on to guacd), but hopefully some patterns will emerge. -Nick
