Community

Hello,
I just opened a ticket with attached logfile because the problem remains unresolved again on 6.10.5.
I hope you can eliminate the bug.
Thank you

Can you share how to isolate this problem? I am having the same difficulty in v 6.10.3.0

First off, RU is an awesome product.  Overall, very happy with the flexibility it allows me.

I've had this 'disconnect' issue as well.  So far I've seen this persist with 6.8.x.x and 6.9.x.x.  I'm currently in a situation where I can't risk attempting a remote upgrade to 6.10.x.x that might fail where I completely lose remote access.  So that'll have to wait - but it sounds like 6.10.x.x are still seeing it.   So I'll share some observations.

This seems to be more nuanced than just simple "network issues" at the host or viewer ends.  The viewer is on a 1 Gbit (roughly symmetic) fiber internet connection.  The host was initially on a admittedly spotty DSL connection, then upgraded to more stable a 50 Mbit cable internet.  The problem remains the same.

Early in the day (east coast, US) remote connections are pretty solid - around 1 PM EDT they start dropping. During this time, bandwidth and latency do drop a bit, but overall do not show any drastic degradation. Around 6 PM EDT, things start improving.

A few observations:
1) If the viewer connects to the host by Internet-ID, the connection fails several times an hour.
2) I can immediately connect my local computer to the host computer network over VPN and the connection no longer fail.  The VPN server is hosted at the same location / network as the host computer.  So at a high level, there's not a drastic change in the connection between the two points - except the use of the Internet-ID.
3) Recently, perhaps most significantly (?), I've noticed that when the connection drops, the main Viewer window displays the "connection error" and the remote host either shows as "Online" (but no longer "Logged On") or briefly moves to "Offline/Unknown" before moving back to "Online".  However, while all of this is happening, for 2 to 4 seconds, I can continue to interact with the remote desktop.  After a few seconds, the remote desktop does eventually "drop".  Upon reconnecting, I can confirm that the actions taken after the "disconnect message" were indeed carried out on the remote host.

This would suggest to me that the issue isn't so much in the remote access connection, but in Internet ID connection status mechanism.  It seems that for some reason, the viewer determines [incorrectly?] that the remote host has gone away and closes a functioning remote access connection.

- Greg

Polina Krasnoborceva wrote:

Hello Michael,

Thank you for your message.

I recommend that you update to the latest version of Remote Utilities and then see if the issue persists.
The latest version is 6.10.5.0 and it's available for download  here .

If the issue persists even after you updated the program, feel free to send us the log files for examination. Here is how to locate the logs:  https://www.remoteutilities.com/support/docs/logging/

Hope that helps.

I did the upgrade to 6.10.5.0 and have seen no change in the behavior. There certainly seem to be enough people having this issue that it isn't a fluke. There must be some systemic problem going on.

-Michael

Michael Jenkins wrote:

Polina Krasnoborceva wrote:

Hello Michael,

Thank you for your message.

I recommend that you upd ate to the latest version of Remote Utilities and then see if the issue persists.
The latest version is 6.10.5.0 and it's available for download   here  .

If the issue persists even after you updated the program, feel free to send us the log files for examination. Here is how to locate the logs:   https://www.remoteutilities.com/support/docs/logging/  

Hope that helps.

I did the upgrade to 6.10.5.0 and have seen no change in the behavior. There certainly seem to be enough people having this issue that it isn't a fluke. There must be some systemic problem going on.

-Michael

Michael,

I've experienced lag and the occasional disconnect issues as well in the past.  Now, I use Internet ID only for initial setup before I can make router port forward/firewall for direct connection to the clients. Now I never see disconnects or lag (12-18ms ping). Hoping to sort out an address book issue and go to my own closer RU relay server (in seattle) to help with sites I don't have router access and avoid their servers altogether.

I'm on the west coast of Canada. I get a better ping to their server in LA (46ms) than their servers in Montreal (84ms), but more often I would get relayed through the Montreal server. Even during problem periods. Right now, for two hosts in the same office, one is on LA and one on Montreal.  There is no special optimization or server selection (or very basic), failover or anything like that in the RUT host.

When I was having very frequent problems some months back, I started pinging the IP shown for "Last IP" in the viewer for their server IP, and I could see very high ping times or drops that correlated with my disconnects and lag. So I ran some tracerts to find out where the loss was happening, and it was happening just outside of the datacenter in Montreal, not the DC or server itself. In such a case, their servers will report very light load server usage and not really highlight a problem for RUT's IT guys (ie, looking for overloaded or down servers). I do not know if they use monitoring services fr om multiple locations, but that would be a good idea.  There's going to be several routes into a major datacenter, but traffic wasn't being routed around the damage. Visitors that relayed through that server that didn't go through the damaged path likely wouldn't have experienced any issue.

The secret ingredient to having reliable, fast connections through a relay server is having servers really close. So on another service that you might not have experienced disconnects, they likely had a much, much higher server presence with servers closer to you (Beam screwer is 33ms fr om me right now). The other ingredient is for the ID to only be used for setting up the connections through NAT routers but letting the two endpoints directly communicate after the tunnel is se t up. RUT have already said they don't plan on implementing this (they will HAVE to change their minds when IPv6 becomes prevalent or else they won't be able to compete with performance of competitors. Heck, even more people having high speed internet connections puts more bandwidth costs on them, especially with a generous free tier...), so my advice for you if you plan on using RUT on more than a few hosts or use it often:

1. Get a Windows VPS from a major datacenter near your location to use as the relay server (I wished they had a linux RU server as those linux VPS' are easy to get for under $30 annually but a Windows VPS is 2-3X that). If they had linux RU server build, RUT could probably make some money by having turnkey private RU servers ready to go if they hosted with a major VPS provider like linode, vultr, digital ocean, etc.  Many VPN companies offer this with a decent markup that helps them fund their business.  Not to mention having better uptime on linux than windows servers for many reasons.

2. Setup direct connections wh ere possible

I would be curious to know what your ping times are to the RUT servers from your location. Run a continuous ping next time you experience issues and see if there is correlation. Then tracert to the IP and see wh ere the problem is happening.