subscribe to our Youtube


14455 questions

17168 answers


0 members

We are migrating to our new platform at Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
141 views 0 comments
by anonymous
I've been code-bashing on the RTU955 via remote connections via RMS.
I keep getting premature ejection on both SSH and Https sessions.
First I thought it was because I neglected to change the default duration when creating the remote access link
it looks like the default is only about 20 min.
After that I set it for several days in length....
However that did not in any way change the summary-execution timeline...
and even that was bizarre because when I got killed, the browser's SSH process still came up with

login: and password: prompts - even though the connection was dead.

So then I kill that session and discover that the whole link, which (I think) still had the several-days-ahead expiry date on it
was also dead...
I had to keep recreating, from scratch, new remote access links which all kept summarily committing suicide out from under my work.

Definitely some brain damage going on there...
Also, when setting up the remote access profile, at first I had only an HTTP connection, I added an SSH connection but it appeared as a second HTTP connectoid. I edited that connectoid and changed the port and the name, such that it appeared to be a valid SSH connectoid, but it was still an HTTPS connection.  I had to delete it and re-create a new SSH connectoid.
Just seems flaky and shaky - non-robust.  I didn't observe this instability while connected directly with ethernet, inside my 7-layer faraday cage laboratory ;-) (not really)

I was trying to config the modbus connection stuff, and test them, but that seemed to be a lost cause.

Sometimes when configuring new modbus connectoids, the name of the connection was retained, but other parameters just got ditched

It isn't clear whether the Save down below Alarms applied to the connectoids too - since they didn't have a save...
Anyway, eventually, after repeated poking I got a rudimentary setup - but the testing function was hopeless... spinning/connecting.............

but no results.  When  the white-screen-of-death overlay appears, the session is screwed.
It seems like browser Back and Refresh are often terminal to the session - need to exit out and recreate a whole new connection link.
Back really should be trapped and not be allowed to terminate the session.  I never want to go "Back" to RMS...  I expect to have to kill the current session to go back to RMS - not have it mysteriously die because I want to get out of a timeout-induced white-spinner-screen

or just refresh the current screen...

We are looking forward to the remote-management capabilities, but things feel pretty sketchy...
At this point the RTU955 is connected to a fast wifi connection and I'm connecting via a fast wired connection.
I imagine when the signals devolve to Cell connections in remote locations, and we're trying to tweak things via cell login to RMS things are likely to get even less robust.   It will have to be space-mission level careful, calculated, meticulous, methodical, patient, careful tweaking

1 Answer

0 votes
by anonymous


Sometimes the sessions disconnect and links expire when using SSH and HTTP. This usually requires the user to generate a new link and can cause frustration from time to time. The team is consistently working on RMS improvements.

Since you want to maintain a remote connection to the device for a relatively long period, consider using RMS VPN. Setting up a VPN connection will allow you to connect to the device without any issues. (Video link HERE)

You can take a look at RMS VPN Quick connect. It is essentially the same VPN, but it is easier to configure and expires in 30min by default. (Link HERE)

Kind Regards,