Loopack connection issue on locked machine

[leapis]

I am having an UltraVNC issue where an outgoing VNC connection abruptly closes in ~10 seconds if the machine is logged in but locked and listen mode is disabled. It does not happen if the machine is logged in or at the Welcome screen. Enabling incoming connections corrects the issue, but I don't want to run in this way.

My test platform has UltraVNC 1.0.9.1 installed as a service on XP SP3 with Accept Socket Connections disabled. The ultravnc.ini has a service_commandline=-connect 192.168.1.3::5500 line, which points to a second machine running the vncviewer in listen mode. If I start the service and then immediately lock the machine, the window appears on the second machine within a few seconds. However, approximately 10 seconds later, it closes, regardless of whether I am in the middle of entering the login credentials to unlock the machine. This poses a problem when the second machine is over a high latency WAN connection, as it can sometimes take almost 10 seconds just to draw the initial screen.

I have tested UltraVNC 1.0.9.3 (beta), 1.0.9.1, and 1.0.8.2 and can reproduce this problem on all of them.

[leapis]

I was able to find the problem, which led to the discovery of two unique issues in the source code. As the 1.0.9.1 source is not available, I am referencing the 1.0.8.2 source.

The first problem is an inconsistency between the debug logging and the program logic. On line 473 of vncmenu.cpp, we have:

<pre>
vnclog.Print(LL_INTERR, VNCLOG("########### vncMenu::AddTrayIcon - User exists, traywnd is not found reset when counter reach %i=20\n"),IconFaultCounter);
</pre>

On line 794, we have this comparison:

<pre>
if (_stricmp(newuser, _this->m_username) != 0 || _this->IconFaultCounter>2) { }
</pre>

When the machine is logged in and locked, IconFaultCounter is going to increase each time the timer fires. By this logic, as soon as it fires three times, it will reset. The debug line indicates it will not reset until 20 counter intervals, so this inconsistency should be fixed.

Changing line 794 to the debug value did greatly increase the amount of time before I get disconnected in a locked state, but it failed to explain why turning on listen mode makes the time interval indefinite. This brought me to line 1558 in vncserver.cpp. Logic was added to flush any clients if the listen socket was no longer enabled. The problem is, it doesn't take in account the case that it was never on but we have an active client connection that we don't want to close. Since the vncServer::SockConnect() method gets called if we switch from not logged in to logged in (or vice versa), this means a user who logs in is also immediately disconnected if they were using an outgoing VNC connection.

The fix I made was to move the Kill/Wait lines into the listening socket block:

<pre>
if (m_socketConn != NULL)
{
// *** JNW - Trying to fix up a lock-up when the listening socket closes
vnclog.Print(LL_INTINFO, VNCLOG("KillAuthClients() fix up a lock-up \r\n"));
KillAuthClients();
KillUnauthClients();
WaitUntilAuthEmpty();
WaitUntilUnauthEmpty();
// Close the socket
delete m_socketConn;
m_socketConn = NULL;
}
</pre>

By doing this, we make sure that the original fix is only done when there was a listening socket in the first place.

[Rudi De Vos]

I will take a look at it

Source code is available:

http://ultravnc.svn.sourceforge.net/vie ... /UltraVNC/

@bottom you have download tarbal, this is the current code.

[redge]

leapis,

do you have also found the known limitation and fix for multi connection from service system via ultravnc.ini like GUI and CLI ?
service_commandline=-connect 192.168.1.3::5500 -connect 192.168.1.4::5500

[redge]

this look like the same old bug... as appear not yet solved..
bug winvnc service_commandline 1.0.6.4 freeze every 30s 10s
bug winvnc service_commandline 1.0.6.4 freeze every 30s 10s

[redge]

confirmed bug of Accept Socket Connections (disabled)

winvnc as service system 1.0.9.3.2
service_commandline=-autoreconnect -connect host

every time you right click on systray winvnc ... open Admin Properties... connection close without crash
and winvnc autoreconnect as request by service_commandline

[redge]

another very easy step to reproduce

[ ]Accept Socket Connection (must be unboxed)
winvnc running as applicaton (not service) (not listening)
vncviewer -listen
service_commandline not needed for test.

winvnc systray... right click... select Add New Client ... hostname... OK
active connection with winvnc reverse connected to vncviewer -listen OK
....
winvnc systray... right click... select Admin properties...
reverse VNC connection closed !!!!

[redge]

[ ]Accept Socket Connection (must be unboxed)
winvnc running as applicaton (not service) (not listening)
vncviewer -listen


winvnc systray... right click... select Add New Client ... hostname... OK
active connection with winvnc reverse connected to vncviewer -listen OK
....
winvnc systray... right click... select Properties...
change the Poll ... OK... active VNC vncviewer listening crash !

[Rudi De Vos]

Corrected in 1.0.9.3.3

[redge]

bug fix: listening disabled and systray,
my own tests above passed OK

[leapis]

That's great news Rudi. I have continued to test this over the last week and haven't found any new problems that it created.