Bug: Autoreconnect function broken on 1.0.9.6

[redge]

In this example, if other viewers (from C, D ...) connect to the server (normal connection), after they quit, the server will open a new connection to B.

B will have more and more connection from the server.

this make no sense if not fixed ?

[YY]

In some particular situation, it is very annoying.

For e.g., for each new connection & quit/drop to the server, it will then open a reconnection to B.

Therefore the active connection of B will be more and more, all from the same server.

If B is required connect to that server only, then you can turn off the listening after the first connection is established. But in case for any reason you need to turn on the listening again, a lot of connection from the server, may be 10, or 100, or more, will come at once. That's what I called Machine Gun Effect.

[Rudi De Vos]

I'm try again...

With -autoreconnect -connect viewerA you tell the server that on each
connect error he need to retry and make a connection to viewerA.

If you have 100 invers connection, on each connection break it use the same rule
"reconnect to viewerA"

serverthread <<<<<<<<<<<<<< This is current handling the autoreconnect (reconnect to viewerA)
-connectionthreadViewerA
-connectionthreadViewerB
-connectionthreadViewerC

All connectthreads just tell the serverthread "I'm disconnected" and the serverthread connected again using his global defined value's. (viewerA)

To fix this
Serverthread
-preconnectthreadViewerA ( keep thrying to connect to viewer until online)
--connectthreadViewerA
-preconnectthreadViewerB ( keep thrying to connect to viewer until online)
--connectthreadViewerB

The connectthread then notify his preconnectthread ( he know the viewer value for that connection and if reconnect was set)
All threads require force closed, cleanup etc... else winvnc go ghost.

This is nothing we can fix in 10961... to complex.

[pgmoney]

The connectthread then notify his preconnectthread ( he know the viewer value for that connection and if reconnect was set)
All threads require force closed, cleanup etc... else winvnc go ghost.

This is nothing we can fix in 10961... to complex.

This isn't a real fix but it will keep it from reconnecting multiple times... but it won't reconnect until there are no other viewers connected either. Which one is the lesser of 2 evils?

Code: Select all

void vncServer::AutoConnectRetry( )
{
//PGM	if ( m_fAutoReconnect && !fShutdownOrdered)
	if ( m_fAutoReconnect && !fShutdownOrdered && AuthClientCount() < 1) //PGM)
	{
		vnclog.Print(LL_INTINFO, VNCLOG("AutoConnectRetry(): started\n"));
		if (m_retry_timeout == 0) m_retry_timeout = SetTimer( NULL, 0, (100), (TIMERPROC)_timerRetryHandler );
	}
}

Code: Select all

void vncServer::_actualTimerRetryHandler()
{
	vnclog.Print(LL_INTINFO, VNCLOG("Attempting AutoReconnect....\n"));
	
	KillTimer( NULL, m_retry_timeout );
	
	
//PGM	if ( m_fAutoReconnect && strlen(m_szAutoReconnectAdr) > 0 && !fShutdownOrdered)
	if ( m_fAutoReconnect && strlen(m_szAutoReconnectAdr) > 0 && !fShutdownOrdered && AuthClientCount() < 1) //PGM
	{

[YY]

Rudi,

I do understand the complexity of problem, and also agree it not the right time of trying to fix on 1.0.9.x., just want to share the redge what I found in an extreme situation. Anyway, thanks for the detail description.


Since having your detail description, I want to ask a final question:

serverthread <<<<<<<<<<<<<< This is current handling the autoreconnect (reconnect to viewerA)
-connectionthreadViewerA
-connectionthreadViewerB
-connectionthreadViewerC

All connectthreads just tell the serverthread "I'm disconnected" and the serverthread connected again using his global defined value's. (viewerA)

Is it possible, when the serverthread received such request, it first check if the global defined value's (viewerA) is already having an active connection ?

If Yes:
Just ignor this reconnection request (unlikely a chance to make two connection to same host/viewer with reverse connection, this should be triggered from a dropped connection to other viewer.... but I wonder if this will have problem with a repeater)

If No:
Obvious the connection to viewerA is dropped, go on to make the reconnection.

[Rudi De Vos]

I tried something, perhaps this behave better

1) autoreconnect (on/off) saved in connectionthreadViewerX
In case the you start winvnc -connect viewerA and make a connection, a disconnect doesn't reconnect.
2) saved host port id in connectionthreadViewerX and just before calling reconnect i save the value's
back in serverthread
This connect back to the correct viewer... unless all viewers drop at the same time.

This solve some issue's.

Only in case there is no viewer online, viewers get removed from list.
(preconnect is realy needed for that)


Behaviour
winvnc -autoreconnect -connect viewerA
(viewer A oflline)
winvnc -autoreconnect -connect viewerB
(viewer A removed, and replaced by B)

winvnc -autoreconnect -connect viewerA
winvnc -connect viewerB
(viewer B connect, viewer A removed after timeout)

(viewer ABC online)
winvnc -autoreconnect -connect viewerA
winvnc -autoreconnect -connect viewerB
winvnc -connect viewerC

On connection break A, reconnect viewerA
On connection break C, do nothing
On connection break B, reconnect viewerB

Server bins updated

[YY]

I tested the 10961 (May 3), but I didn't see the results you said.

Test 1
winvnc -autoreconnect -connect viewerA
(viewer A offline)
Never initiate any reconnection.

Test 2
winvnc -autoreconnect -connect viewerA
(viewer A offline)
winvnc -autoreconnect -connect viewerB
(viewer B is online & connected)
I don't see any reconnection if B dropped.


Test 3
winvnc -autoreconnect -connect viewerA
(viewer A is online & connected)
winvnc -autoreconnect -connect viewerB
(viewer B is online & connected)
I don't see any any reconnection if B dropped

Only in case there is no viewer online, viewers get removed from list.
(preconnect is realy needed for that)

I don't understand.
Do you mean if there is no any active connection, all the viewers (need to be reconnected) will be moved ? or

The autoreconnect to particular viewer is valid only if a successful connection has be established ?

[Rudi De Vos]

I will retest again

[decapeter2]

hello,
i've the same problem for the autoreconnect.
i have 4 remote PC runing vnc as service connected to a repeater on my computer. for 2 PC all is ok connect/deconnect/reconnect/etc... but for 2 others PC, i only have the fist connection when the windows session is loaded but after that, the autoreconnect fail...
i have write the command line in the "misc" fild in "edit settings" of uvnc :

Code: Select all

-autoreconnect ID:123456789 -connect x.x.x.x:port

why only 2 PC work and not all ? (they all have a diferent ID)

thanks

[YY]

Have tested 10961 (May 6)


IT NOW PASS ALL MY TESTS, and doing the autoreconnect function exactly as what I expected it should be.

1. In initiate a new connection, it will retry (& retry) if the connection not able be established.
2. When issue a new reconnect command (to another host), the -autoreconnect switches to the new destination properly.
3. When connection dropped, the autoreconnect trying to re-establish the connection.
4. Working properly with both commandline_service= & winvnc.exe injection.
5. No more Machine Gun Effect .

Good Work Rudi !!!

But I would like to ask more ...

1. other than having the "autoreconnect" feature at commandline, I suggest this should be at option at GUI. I think this should be added on the "Add New Client" interface ... such as a check box.

2. I think the server should have a way to show the host that are being configured as autoreconnect to. I think this should be added on the "List All Clients" interface

But if these need too much code job and time, I think it is OK be implement in next release.



After the good news, there is still a bug .... not the "-autoreconnect" itself, but something related to it ..... the "-stopreconnect" .

I found this option not working, I cannot use it to stop the server's autoreconnection action,
but I think this should be not difficult to get it fixed.

[Rudi De Vos]

stopreconnect

stopreconnect set the global reconnect to false....
But with the changes the autoreconnect is saved per viewer, so if a viewer has autoreconnect set,
it push it to global on disconnect and overwrite the stopconnect value.

stopreconnect doesn't make sense at global level.
For now, i will see if i can replace it by
-stopreconnectall
Tell all running connections to set reconnect to false....

[decapeter2]

i've tried this :
1. set the service_command with autoreconnect
2. down et boot up the computer
3. if i do nothing on the computer, there is no connection to the repeater

1. set the service_command with autoreconnect
2. down et boot up the computer
3. just open properties by right clic the winvnc system tray icon -> then i have the connection to the repeater...

1. set the service_command with autoreconnect
2. down et boot up the computer
3. close windows session and reopen it -> then i have the connection to the repeater...

so i cant use my remote computer becose the autoreconnect function doesnt work if nobody is on the remote computer...

winvnc 1.0.9.6 x64

[YY]

stopreconnect doesn't make sense at global level.
For now, i will see if i can replace it by
-stopreconnectall
Tell all running connections to set reconnect to false....

But in my test, it seems there was only ONE HOST able be reconnected.

I need to do some more tests to verify this ...

[YY]

OK, further tests proved that, ALL established connections can be autoreconnected if any one of them is dropped.

The only problem is that if two connections are dropped at very close time, the first one will lose the autoreconnect setting.


Here is my summaries based on my tests to 10961 (May 6)

1. To establish a new connection, ONLY ONE remote viewer will have the autoreconnection action, i.e the viewer of the latest command.

2. For recovery of established but dropped connection, all of them have the autoreconnection action.

3. However, if two established connections are dropped at very close time, the server can just able to handle the reconnection of later one. The 1st dropped viewer, the autoreconnection action to it will be removed PERMANENTLY.


All my tests are done with 32bit winvnc.exe, reverse connection on WinXP.
If I have spare time, I will try some test of the autoreconnect to a repeater.

[YY]

stopreconnect doesn't make sense at global level.
For now, i will see if i can replace it by
-stopreconnectall
Tell all running connections to set reconnect to false....

It will be perfect if this option can also allow to specify a particular viewer, e.g.

-stopreconnect viewer_A
-stopreconnect viewer_B
-stopreconnect all

[Rudi De Vos]

not possible, changed is made like this

-stopreconnect
1) Tell all connected clients to disable autoreconnect
2) Tell the connection that is looping to connect to a viewer ( until online) to stop the loop

bins updated

[YY]

not possible, changed is made like this

-stopreconnect
1) Tell all connected clients to disable autoreconnect
2) Tell the connection that is looping to connect to a viewer ( until online) to stop the loop

bins updated

OK! No problem.
Have tested the -stopreconnect of 10961 (May 10). It works properly.


However, still found some issues on the autoreconnect function.

Here the server (10961 (May 10)) is running as service:
1. -autoreconnect -connect viewer_A (it is offline)

2. try connect to viewer_B via "Add New Client)"

　　if viewer_B is offline .... Message: "Failed to connect listening viewer" ....autoconnect to viewer_A is keep on running.

　　if viewer_B is online & connection established .... autoconnect to viewer_A is SUSPENDED .... after the connection to viewer_B ended, the autoconnect to viewer_A resume.

3. If the connection to viewer_B is excuted via commandline:
　　winvnc.exe -connect viewer_B

　 Even not autoreconnect to viewer_B, the autoreconnection to viewer_A was removed PERMANENTLY.



Another issue is:
1. -autoreconnect -connect viewer_A (it is offline)

2. If there happened any drop of established connection (have reconnection setted), that connection will be re-established without problem, but the autoreconnection to viewer_A was removed PERMANENTLY.


Any chance that these be improved / fixed ?

[Rudi De Vos]

That's the best we can do with the current engine..
There is only one reconnect engine, this can be used for offline viewer or reconnect from a connected viewer.
Reconnect has priority, kicking the offline viewer permanent.

Each connection require his own engine to fix this...not possible without deep code changes -> 1097

[YY]

OK! I do agree the 10961 (May 10) is good enough for most situation.

It may be not a good idea to make too much change, if it is necessary to make large scale of code change. as this may introduce new problem or new bug.

[Rudi De Vos]

yep, indeed
A lot of time by you and other would be lost if making some deep changes introduce back other bugs...

[decapeter2]

ok i've tested this:
TEST 1 :
- boot up 4 remote computers automaticaly with BIOS setup at 9am with autoreconnect to my repeater
- lunch the repeater on my computer at 12am
-> i have only one computer connected to the repeater.

TEST 2 :
- lunch the repeater on my computer at 8am
- boot up 4 remote computers automaticaly with BIOS setup at 9am with autoreconnect to my repeater
-> i can see all remote computer on the repeater.

so the autoreconnect function stop to retry after a long time?

[B]

decap, that sounds similar to my Bug #1 for v. 1.0.8.2 at http://forum.ultravnc.info/viewtopic.php?t=18351

But I thought it had been fixed...

[decapeter2]

Thank you B for your answer. I use the 1.0.9.6 x64 on win7 with video driver.

[decapeter2]

today i've tried this :

- server 1.0.9.6 x64 connected to repeater with autoreconnect and MSRC4plugin
- viewer 1.0.8.2 x32 (security version) in normal connexion with MSRC4plugin (fill fields manualy and lunch connexion)

- if i droped the password, the server never autoreconnect
- if i do a mistake on the password, the server never autoreconnect
- if the viewer crash (for some reason), the server never autoreconnect

[rcooke]

I'm testing 1.0.9.6.1 (build May 18) on two WIN XP Pro computers.

With the SCplugin enabled and a password set (in uVNC).

The server is set to autoconnect to the PERL repeater in ChunkVNC 3.2.

When the Client computer direct connects to the server (not using the repeater) and I CANCEL the password box, the server remains available for re-connects, the repeater connection is listed as a "pending" connection, and the green eyeball is in the system tray - all normal.

But, if I do the same test through the repeater the repeater connection vanishes from the "list all clients" dialog. The Green eye is still in the system tray, and Windows Services says "uvnc_service" is still running. I cannot get a subsequent remote connection through the repeater to work.

When I tried a direct connection, the remote desktop window opens for a second then closes. The viewer is sucking up lots of CPU, but without the window you have to use Task Manager to kill it. I enabled the console on my next test and got this error report:

Error 10053: An established connection was aborted by the software in the host machine

My second direct connection attempt worked fine. I used it to restart the service. And verified the repeater connection was back on the pending list.

I enabled the console for my abortive connection test via the repeater and discovered after I cancel the login box and cancel the connection box, the error in the console is "Unknown error 10053". Curiously, when I then attempted direct connection it worked on the first try, I did not get the error I got in my first test.

I added a passphrase password and repeated my test and found again that via the repeater canceling the password box disables the repeater autologin, but leaves the service running.

Is this enough info to find the source bug and attempt a fix? Or any workaround suggestions? I already suggested not cancelling the password box, didn't go over well with the users....... heheheh no sense of humor.

[swemabj]

Have anyone found a workaround for this issue that WinVNC 1.0.9.6.1 (using -autoreconnect) stops reconnecting to the repeater if a login attempt from VNC viewer is interupted (or cancelled by the user)?