Losing the ability to establish a VNC Connection

Over the last week, we have had three separate sites on three different days which suddenly lost the ability to connect using a VNC connection over Talk2M. When we log-in, and attempt to establish a VNC connection, we get a message which states, “An internal error has occurred within the server, and the connection has been terminated. Maybe the VNC password is wrong.”

We have not changed any software, firmware, or settings in the device hosting the VNC connection on our end. We have seen this message in the past, but it has always been a temporary issue which has self-cleared. This is the first time I’ve seen this message last for days without self-clearing.

To resolve this issue, I wind up having to reboot the VNC host device.
Once I reboot the host, the VNC connection is once again available over Talk2M.
Any chance that this is a Talk2M issue?

Hello, @mitchell.hein!

It sounds to me like the issue was within the VNC host device; however, we would not be able to tell for certain unless we could troubleshoot while it was producing the error. To troubleshoot an error like this, we would typically ask you to reboot the VNC host device, and if still persisting, reboot the eWON. Because a reboot of the host device resolved the issue, I do think the error was within that device.

Typically any type of VNC connection issues with Talk2M are going to be due to missing or errant network or port configurations.

Please let us know if you have any other questions!

Best regards,

Hi Ashley,

I’d agree that the HMI (or VNC host) would normally be the first suspect.

First, we must consider that we’ve had 4 years of communication experience at 28 sites without this situation.
Second, we know there have been no changes at all to our VNC host’s firmware, software, or settings within the last year or longer.
Third, we have now had three such VNC failure events at different sites in a single week. (One still currently active).

Coincidence? Unlikely. This chance of the coincidence that three independent sites would suddenly start exhibiting the exact same failure in such a short timeframe is very low. So low that I don’t accept it.

So… Let us assume that the issue is with the Talk2M side. What would that issue look like?

I’d suggest that a change to the Talk2M VNC server is now forcing a “license” or “connection” to expire after a given length of time, where it didn’t used to do that. Now, days, weeks, or months after this alleged change, we are starting to see that sites which have not lost power for a that length of time are kicked off, and are not allowed to use the VNC server again until they are rebooted and can establish a fresh connection or are granted a new license.

Please investigate this possibility for me. Thanks!

Best Regards,


Would you be able to private message me a backup with support files from your eWON?

How to send a private message:

You should be able to drag and drop the .tar file into the message box.

Make sure when generating a Backup through eBuddy that you select “include Support Files”, seen below.


I will check with the server team in Belgium to see if they are aware of any changes that may affect VNC connection over the last week.

Please let me know if you have any issues private messaging me those backup files.

Best regards,

I’m in the process now of obtaining the backup, but I don’t believe it will help you. I’ve checked the Event Log and Real Time Log, and there are no eWON faults, warnings, or anything in the traces to suggest an issue with the VNC connection.

This device is currently in this faulted condition, but I can’t leave it like that all weekend.
I doubt I can wait for the server team to review it before I need to reset it.

I will send you our account name and the device name by private message.

Jordan and the other staffers there in Pittsburgh used to have the means of looking right into the server’s logs themselves, as far as I know. Hopefully, we can have someone look at the offending connection before I need to reset the fault.

@mitchell.hein, thanks for that backup file. We were able to look into the server’s logs and don’t see any errors, only disconnects and reconnects from different users.

I did notice that the tunnel is set to UDP–setting it to force TCP would provide a more stable connection if you would like to try that. Additionally, upgrading the firmware to the newest release may provide some relief as there have been stabilization improvements in the newer versions. Additionally, upgrading the firmware may provide relief due to noise on the LAN side. On newer versions, the eWON’s internal switch will reset the port if it detects a timeout due to EMI.

When the VNC connection goes down, are you still able to ping the LAN interface of the eWON?

Let’s try updating the firmware to 12.1 first, and possibly force a TCP tunnel to further stabilize the connection.

Best regards,

Ping? Yes.
We haven’t lost the ONLINE status, and when we connect, we can ping the devices on the eWON’s LAN.

We use UDP because it is required to upload, download, and monitor our PLC and HMI at the site.
Although, we may be incorrect in this, as we may be able to do UDP over the VPN even if we “force TCP”.
I’m unsure about that.

I’m out of time today, and will need to reset the HMI for the weekend.

I fully expect that this situation will continue at other sites.
We will have an opportunity to troubleshoot further that that time.
If the problem doesn’t ever surface again, then so much the better and I’ll admit it really was a wild coincidence. (grin)

Thank you for the assistance, and have a good weekend!
Best Regards,

As I expected, we had another system which lost the ability to establish a VNC connection this weekend.
However, I dug into the issue a bit further, and determined that the eWON is NOT the issue.

It seems my HMI was still connected to the network, and DID respond to a “ping”.
However, its global variables could not be read by the PLC, and it could not be reached by HTTP or FTP protocols.

Once I rebooted the HMI (by downloading a fresh copy of the same application), all functionality was restored.
I will be pursuing this with our HMI vendor.
Thanks for your support, and patience through this troubleshooting process.

[EDIT: The root cause was the HMI firmware. A newer version of firmware in the HMI solved the problem.]


Fantastic–I am glad you were able to nail the issue down! Thank you very much for the follow up. Please do not hesitate to respond with any further questions or concerns.

Best regards,