Question

I have a RUT955 connected to a LAN switch with 5 embedded computers.

I have managed to access all of them through Remote SSH on the RMS web portal, which works fine.

However, using the Remote Desktop connection on the RMS portal works only for a few seconds, is not responsive at all, and then says "Timeout." I have enable a port forwarding rule on the router and setup my IP tables on the (linux) embedded computers which allows a connection on port 5900 through the firewalls.

Is the timeout connection because of network speed, or another reason? Any assistance would be appreciated.

Answer 1

Hi,

It could be because of the network speed as you said, if it's quite low - buffer might not be able to keep up with the elements on the screen appearing and results in a timeout. What WAN are you using? Mobile, Wired WAN, or connected to an access point? I would suggest switching between those and see if different speeds, pings give you any difference.

Also, make sure you're not running any aggressive antivirus on your computer, it could be that it's killing the connection once it detects it.

EB.

Comments

Hi There,

Thank you for the quick response.

I have a wired WAN connection, as well as a Mobile failover, I have tested both with the same result. This is a best-case scenario for internet speeds, since the system will mostly operate in remote environments with much slower speeds, in which case I would have to resort to SSH (which is mostly sufficient for my monitoring/support services).

Our company does have quite an aggressive corporate antivirus software, so I will look into that. But, if it was the antivirus killing the connection, would it not have done so with the remote SSH connections as well?

Josua.

---

Incoming and outgoing connections work differently, so if it's an incoming connection that was not mentioned in the firewall or antivirus - any firewall/antivirus software could be killing the connection instantly. As SSH is more common - antivirus could have it opened.

EB.

---

Hi there,

Thank you for the info. I have checked with out IT security, and there are no port being blocked, so it must be a slow internet connection.

But that doesn't really make sense because both our wired and 4G internet connection have quite fast speeds, fast enough to run a very responsive Teamviewer session.

Any other possibilities you can think of?

Josua.

---

What kind of OS you're running? Do you have all the updates of it installed?

Have you tried resetting the device? Or checking if there's a newer firmware update available?

Are you using network-level authentication?

Which protocol do you use? VNC or RDP?

EB.

---

Hi there, 

The OS on the embedded devices I am trying to access are both linux based (JetPack which is an Ubuntu flavour and Raspberry Pi OS). I will try updating the embedded devices' with the latest packages, but doubt this would solve the problem since it happens when I try to access both the Jetson Nano running Ubuntu and the Raspberry Pi running Raspi OS.

I have tried resetting the router, and I am sure it is on the newest firmware (FW ver.: RUT9XX_R_00.06.07.5)

I am using network level authentication, and I'm using VNC protocol.

---

Is there a way for you to use RDP instead? Not sure if that would solve the issue you're having, but worth a shot.

If with RDP you will be unable to connect - I will report your issue to RnD and see what they can do about it.

EB.

---

Hello,

Nasty issue, I had a similar case the cause was a MTU to high for some paths in the network. Fine for a link between two locations here but unusable for a link between the US and Europe. The underlying reason was a switch from IPv4 to IPv6 and back, reducing the "effectively available" packet size. For wireguard you can have a 1460 bytes MTU in "local" only but you must restrict it to 1420 bytes for US-Europe use.

Could it be the same for RMS ? It uses a VPN with UDP.

If you have tcpdump on the embedded computers you can do the following:

   tcpdump -i any -n -v -s 0 -w vnc.pcap 'icmp or port 5900', stop a soon as you have the timeout.

I can help to analyse the dump if you are interested (via PM).

Regards,