Home AMX User Forum AMXForums Archive Threads AMX Hardware

VNC problem with 8400

I have an 8400 out in the wild that regularly loses it's ability to accept a VNC connection. It is still online, and still works locally, you just can't VNC into it. If you telnet the master and send it a reboot command, it's fine for a while; in a week or two, it will stop accepting connections again and need another reboot. The customer relies on the VNC heavily ... it's his way of monitoring his many homes when he is not actively staying in them. I have been forestalling the issue with him only by regularly checking on it myself, and rebooting it before he notices there is a problem, but it's tiresome, and I don't want to be forced to reboot it daily as a workaround if I can help it. The panel firmwares is 2.85.14, and the master 3.50.430. I'm hesitant to upgrade to 2.86 unless it specifically speaks to this issue (officially or not). There are some items in the 2.86 release that look like they may be pertinent, but some re-enforcing feedback would be good before I pull the trigger.

I don't know if it has any bearing on the matter, but the client himself uses UltraVNC to connect (RealVNC is not an option, he has an remote maintainence contract on his PC's, and the service uses the RealVNC server; since their default installation only installs the server, whenever they see the client, they uninstall it. They tell me this behavior can't be changed). It is possible it leaves it up and the connection times out before he closes it, but I can't be sure of that, it's just a hunch based on what I know of this guy. Also for whatever it's worth, this is the same property that I had an NI-3100 continually falling off line (which is now resolved, though we never did figure out what caused it in the first place).

Any thoughts or resolved similar experiences? I am seriously hampered in this case by the fact that the client is a bit volatile, and we are trying to get this done under his radar to avoid an explosion. Experiments and site visits are not really an option. I am going to be bouncing this off tech support as well, but I suspect I am going to get a "we aren't aware of any such problem" kind of answer.

Comments

  • Thomas HayesThomas Hayes Posts: 1,164
    Hi Dave, I have this panel on my desk and hooked to my home system for about a week + with no issues so far, I'm running RealVNC at the moment but will try to download UltraVNC and test it for you.
  • DHawthorneDHawthorne Posts: 4,584
    Hi Dave, I have this panel on my desk and hooked to my home system for about a week + with no issues so far, I'm running RealVNC at the moment but will try to download UltraVNC and test it for you.

    One scenario which I suspect may apply to this customer is that he is letting the connection time out rather than closing it when he is done. I have a hunch though that this is not VNC client related so much as a "dirty" Internet connection. Too many screwball issues with this site, and it is in a remote location.

    I do appreciate your effort though, thanks.
  • Thomas HayesThomas Hayes Posts: 1,164
    Let me try the time out issue right now Dave, i'll post the reply ASAP.
  • CT-DallasCT-Dallas Posts: 157
    I only use UltraVNC and have connected to 8400s without issue in the past. Occasionally, but not limited to 8400's, I have difficulty reconnecting to panels. The issue seems to revolve around the panel thinking the previous connection is still in progress and it blocks the subsequent connection attempts. The only cures I have seen for this would be a device connection timeout that in essence free's up the connection after an unidentified time period, or to reboot the panel like you are doing. Neither are great, but as an UltraVNC user, I have observed similar behavior. This could be a short coming in how UltraVNC terminates the session.
  • DHawthorneDHawthorne Posts: 4,584
    CT-Dallas wrote: »
    I only use UltraVNC and have connected to 8400s without issue in the past. Occasionally, but not limited to 8400's, I have difficulty reconnecting to panels. The issue seems to revolve around the panel thinking the previous connection is still in progress and it blocks the subsequent connection attempts. The only cures I have seen for this would be a device connection timeout that in essence free's up the connection after an unidentified time period, or to reboot the panel like you are doing. Neither are great, but as an UltraVNC user, I have observed similar behavior. This could be a short coming in how UltraVNC terminates the session.

    Well, the panel has a timeout setting, it ought to kill it even if the VNC client doesn't.
Sign In or Register to comment.