Issue when server loses ethernet connection.

[DaleStan]

I have discovered an issue that seems to be triggered when the machine that a UltraVNC server loses its Ethernet connection for several seconds[0][1]. Once this happens, the server gets into a state where it will acknowledge connections on the TCP level, but never send its protocol version, thus making it impossible for a viewer to connect.

I have discovered two methods of getting the server to respond again, both functionally identical: (1) Reboot the computer, or (2) kill both winvnc processes (merely stopping the service only gets rid of one when the server is in this state) and restart the service.

I have packet captures exhibiting both a failed connection (which consists of a TCP three-way handshake followed by over a minute of TCP keep-alives, after which I got tired of waiting) and a successful connection (Another three way handshake, this time followed by the server sending its protocol version, the client responding in kind, and everything progressing as expected.) but I'm not convinced they're interesting beyond those details. If, however, anyone thinks they would be interesting, I can post them.

Both server and viewer are on 32-bit Win XP SP3, and are version 1.0.9.5. The server is running as a service under the Local System account.

What can I change on the server to alleviate this issue? Is there other information I could provide that would shed more light on it?


[0] "Several seconds", in this context, means "a minimum of 10 to 15 seconds". I did not do any particularly precise timing, but an approximately 5 second disconnect did not trigger this issue, while an approximately 15 second disconnect did. All disconnects longer than 15 seconds also triggered this issue.
[1] The reason for this connection loss seems to be immaterial; I observe the same behaviour both when the ethernet cable is unplugged and when the router power-cycled.

[DaleStan]

New information, maybe:

1) Fifteen seconds may not be sufficient to trigger this issue. I have not yet had disconnections of 30 seconds or more fail to trigger this issue.
2) I am now able to reproduce this on my (VMware ESXi hosted) virtual machines, by changing the machine settings to disconnect and reconnect one of the the network adapters.
2b) Because it's a lot easier if my VMs have two IP addresses, they have two adapters. (The real hardware only has one adapter.) If I disconnect either adapter, wait, and reconnect that adapter, all subsequent UltraVNC connections will fail, regardless of which adapter/IP I use.

[B]

You may be aware that UltraVNC has long had issues with any changes to the network configuration after the point at which the server / service was started. (I mentioned this in a bug roundup here a year or two ago.) It just never checked to see if anything changed, or otherwise noticed.

At least some of that was supposed to be addressed in the 1.0.9.x series, but apparently it's not quite perfected.

[DaleStan]

Well, I did some more testing, starting with verifying that it wasn't present in 1.0.2, which we were using when were an XP-only shop. Then I figured I might as well try 1.0.9.6.1 too.
Good news: It seems to be fixed in 1.0.9.6.1.
Bad news: Now I get to figure out how to upgrade way too many headless computers upon which uVNC may or may not be working. (Fortunately they respond to things like taskkill, sc, and shutdown, so I can do this; it just isn't going to be as easy as I'd like.)

[B]

Oh good; for some reason I thought you were already using the latest version.