Bug: Autoreconnect function broken on 1.0.9.6

[YY]

Found the -autoreconnect is not function on 1.0.9.6 server.

Test condition:
UVNC server running as service on WinXP, excute following command:

Code: Select all

winvnc.exe -autoreconnect -connect xx.xx.xx.xx (to a listening viewer)

　　or

Code: Select all

winvnc.exe -autoreconnect ID:1234 -connect xx.xx.xx.xx (to a repeater)

No reconnect action is taken place if the communication is dropped.



Doing same test on 1.0.9.5 and 1.0.8.2, both working properly.

[Sainsuper]

if you use winvnc as application the syntax us:
winvnc.exe -autoreconnect -connect x.x.x.x -run

if you use winvnc as service you must adding:

service_commandline=-autoreconnect -connect x.x.x.x or
service_commandline=-autoreconnect ID:1234 -connect x.x.x.x (repeater)

in ultravnc.ini

i heve tested it and it works good.
regard

[YY]

Thanks for your verification.

But neither of your testing are what I'm talking about.

In my test, the winvnc.exe is already running as a service, and then I excute the command:

winvnc.exe -autoreconnect -connect xx.xx.xx.xx

　or

winvnc.exe -autoreconnect ID:1234 -connect xx.xx.xx.xx


These are one of the proper ways to ask the uvnc server to make a connection with autoreconnect feature. This method exists even before the introduction of service_commandline= in ultravnc.ini.

It still works on 1.0.9.5 and 1.0.8.2 (I suppose works any version before), you can try.
Just not working on the 1.0.9.6, or unless it is dropped by intent.

[Nick_ua]

hi all
I have a question
I have installed server version 1,0,9,6
I use SecureVNCPlugin.dsm
through repeater
when I connect to server Uvnc is the password prompt,
if i click cancel
the server Uvnc will not reconnect to the repeater

If I enter the password and connect to the server Uvnc and then disconnects
then server Uvnc reconnect to the repeter

I can not understand why this is happening
maybe I missed a setting

I hope you understand me

Code: Select all

service_commandline=-autoreconnect ID:1234 -connect xx.xx.xx.xx

[YY]

when I connect to server Uvnc is the password prompt,
if i click cancel
the server Uvnc will not reconnect to the repeater

If I enter the password and connect to the server Uvnc and then disconnects
then server Uvnc reconnect to the repeter

I can repeat this problem.

I don't know why this happened, but looks like this is caused by the SecureVNC Plugin.

[Sainsuper]

YY, sorry but only now i have unstarstand!!

I did further investigation and I found the same problem.

[YY]

I did further investigation and I found the same problem.

Nice to know others can repeat my result.

Looks there are a lot of issues with the "autoreconnect" function.

[theo100]

I can't get the autoreconnect function to work under the service . In the ultravnc.ini file i added: service_commandline=-autoreconnect -connect x.x.x.x .
It works when the server is run as application. (winvnc.exe -autoreconnect -connect x.x.x.x) . I downgraded the server to 1.0.9.5 but also no luck.

[YY]

The 1.0.9.5 works fine in my test as a service, with the
service_commandline=-autoreconnect -connect x.x.x.x


Before connection established, the winvnc.exe tries to call the viewer for every 30 second.
I tested on a WinXP Pro.

[theo100]

I use xp pro as well, does it matter where the service_commandline is placed, bottom or top of file?

[YY]

Not sure! I had never changed the sequency of any items inside the ultravnc.ini


But you may delete (or rename it) the ultravnc.ini, and run the winvnc.exe again (remember to do this in application mode) so that to generate a good new file.

[redge]

please check all listed bugs are solved 1.0.9.6.1
[post=85761][/post]

[redge]

winvnc 10961 (16 april) service mode winvnc multi connection still fail

1. vncviewer -listen 5500

2. service_commandline=-autoreconnect id:1234 -connect repeaterhost
or
service_commandline=-autoreconnect id:1234 -connect repeaterhost -connect hostname


viewer connect to repeater with same id OK and leave live it and start cmd


C:\>\UltraVNC\winvnc.exe -autoreconnect -connect xx.xx.xx.xx (to a listening viewer)
result: invalid protocol at vncviewer !
or
C:\>\UltraVNC\winvnc.exe -connect xx.xx.xx.xx (to a listening viewer)
result: invalid protocol

winvnc as service commandlineif there no connection should wait network up (treadsafe) without pop up as service on logon screen

[theo100]

Did some more testing with 1095 and 1096, the results are the same for both versions.
With server started as service and -autoreconnect -connect added in the ini file the autoreconnect connect function does not work.
With the server started as service and later started as application and the viewer set to -autoconnect -connect -listen also not working.
Only when i start the server as application with -autoreconnect -connect and the viewer on -listen the connection is made automatically and restored when interrupted. It looks like something is wrong with the service.

[Sainsuper]

i have tested winvnc service and service_commandline and it works good

viewer set to -autoconnect -connect -listen

i think this is incorrect

start viewer in a pc with
vncviewer.exe -listen 5500

in a server:

delete ultravnc.ini and start winvc as application so it create a clean ultravnc.ini
close winvnc

modifiy ultravnc in [admin] section and add
service_commandline=-autoreconnect -connect x.x.x.x:5500

install service
when winvnc start as service it reads ultravnc.ini and connect to address written in the service_commandline.

[YY]

Test condition:
UVNC server running as service on WinXP, excute following command:

Code: Select all

winvnc.exe -autoreconnect -connect xx.xx.xx.xx (to a listening viewer)

　　or

Code: Select all

winvnc.exe -autoreconnect ID:1234 -connect xx.xx.xx.xx (to a repeater)

No reconnect action is taken place if the communication is dropped.

Doing the same tests on 10961 dated 18-Apr-2011, still having the same issue.

[theo100]

Gave it another try, after much attempts got the service autoreconnecting to viewer in listen mode.
I started with a clean .ini as sainsuper suggested, but the service_commandline... has to be before the [ultravnc] line in the .ini file! else it does not work.
Unfortunately i still can't get the viewer to autoreconnect to the service, this should be the default way but it does not work. Suggestions anybody?

[YY]

theo100,

See this thread for what I found on VNCviewer's autoreconnect.
[topic=28011]VNCviewer's AutoReconnect Characteristics[/topic]

[theo100]

YY,

If you setup Uvnc as i described earlier it does what you requested in your other thread. The server makes the connection and the viewer just listens out. if the connection is dropped and later repaired the server will automatically make the connection again. (handy with wireless links). I am trying to make multiple viewers autoconnect to one server (see this topic: Autoreconnect to multiple viewers) unfortunately this still does not work.

[YY]

Found the -autoreconnect is not function on 1.0.9.6 server.

Test condition:
UVNC server running as service on WinXP, excute following command:

Code: Select all

winvnc.exe -autoreconnect -connect xx.xx.xx.xx (to a listening viewer)

　　or

Code: Select all

winvnc.exe -autoreconnect ID:1234 -connect xx.xx.xx.xx (to a repeater)

No reconnect action is taken place if the communication is dropped.

Has tested the Server 10961 (Apr.26). Now the -autoreconnect comes back, but also found some issues (some may be existed in past version but not yet reported, I don't have enough time to verify)

First Problem

The interval between each reconnection will increase by 10 seconds if not got connected.

In an actual measure, the time values between each reconnection are (in seconds):

5, 15, 25, 35, 45, ........

The problem exists in all operation mode:
- service with autoreconnect defined in service_commandline=
- service and then autoreconnect injected from winvnc.exe
- application mode



Second Problem

The server will incorrectly making connection to viewer even connection has been establish.

Here is the scenario of this issue:

1. the server is running as a service
2. A user excutes a command to a listening viewer:
　　winvnc.exe -autoreconnect -connect remote_viewer_A
3. The user excute the command again (may be to another viewer, may be he mistype the spelling of remote_viewer_A):
　　winvnc.exe -autoreconnect -connect remote_viewer_B

Now the remote_viewer_B will be connected, but there are TWO connection sessions made.



Here is a more interesting scenario:

1. the server is running as a service
2. A user excutes a command to a listening viewer:
　　winvnc.exe -autoreconnect -connect remote_viewer_A (assume remote_viewer_A is not running)
3. Then the user excute the command again:
　　winvnc.exe -autoreconnect -connect remote_viewer_B (remote_viewer_B is not running either)
4. the user excute the command again:
　　winvnc.exe -autoreconnect -connect remote_viewer_C

Well the remote_viewer_C will be connected, but the server will KEEP ON MAKING new connection to the remote_viewer_C.


Here is another similar scenario:

1. the server is running as service with service_commandline=-autoreconnect -connect remote_viewer_A
2. A user excutes the command winvnc.exe -autoreconnect -connect remote_viewer_B

Now the remote_viewer_B will be connected, but there are TWO connection session made.



Third Problem

There is no way to cancel the autoreconnect operation that has instructed to the server, unless the server is restarted.

[Rudi De Vos]

Autoreconnect was never made to work like that.

1) growing timeout, added on request to avoid that in case the viewer doesn't accept you get a lot of accept/treject message on the screen.

2)Autoreconnect remember the commandline.
There is only one commandline, value is overwriten.

winvnc -autoreconnect -connect vA -> commandline remember VA
winvnc -autoreconnect -connect vB -> commandline remember VB and overwrite VA

This is exact what you desscribe, last parameter entered is used.

This has been like this since we added the auto reconnect option.
Was this ever working...

And indeed, once set on, there is no option to disable.

[Rudi De Vos]

Taking a deeper look at the code... it's bad.

Server autoreconnect can't proper function with multiple viewer connections.

The connection is made in the message handler, if second viewer is unavailable the handler lock, blocking also the running connection for
several messages...

Complete rewrite needed of that part, deep in the code...

Not possible as fix for 10961, to many ways to add bugs.

[YY]

Is it possible and easier just to write some code that can clear any previous antoreconnect instruction ?

If this code is available:
1. A user can cancel the antoreconnect action if he want to.
2, If a user issued an autoreconnect instruction, this code should be run first to clear any previous action (if exist, include the one in service_commandline=), to ensure only one antoreconnect is in action, and avoid the reported problem.


I understand the UltraVNV was not made to handle multi autoreconnect. It is OK if it can handle one at one time, although some users may disappoint.

The present problem is a user may have a chance to connect to different viewers ...the 1st, 2nd, 3rd (one and then another)...and so on. Like the situation of Second Problem, the server becomes a machine gun and firing remote_viewer_C

1) growing timeout, added on request to avoid that in case the viewer doesn't accept you get a lot of accept/treject message on the screen.

It OK for this consideration.
Just suggest have this information put on UltraVNC document.

[YY]

Tried the 10961 (Apr.28)

1. Basic function of -autoreconnect

　　- Application mode -- OK
　　- Service + service_commandline= -autoreconnect -connect xx.xx.xx.xx ..... -- OK
　　- Service + winvnc.exe injection -- Not Working. After initial connection trial, no further reconnection.
　　　However, if the -autoreconnect has been started with service_commandline=, I can use the winvnc.exe injection to change the -autoreconnect to another host:port.



2. Basic function of -stopreconnect

　　Works properly in my test, on both application mode & service mode.



3. Reconnect Interval

　　Rather than growing timeout, now it is fixed with 10 seconds between each reconnect.



4. Bug of Machine Gun Effect

Here is a more interesting scenario:

1. the server is running as a service
2. A user excutes a command to a listening viewer:
　　winvnc.exe -autoreconnect -connect remote_viewer_A (assume remote_viewer_A is not running)
3. Then the user excute the command again:
　　winvnc.exe -autoreconnect -connect remote_viewer_B (remote_viewer_B is not running either)
4. the user excute the command again:
　　winvnc.exe -autoreconnect -connect remote_viewer_C

Well the remote_viewer_C will be connected, but the server will KEEP ON MAKING new connection to the remote_viewer_C.

Still exist!! Only slower.
　　Looks like the server will try to open new connection for every 10 seconds. I suspect the bug is due to the server didn't get the correct status (the listening viewer has been connected), so the autoreconnect code tried to open new connection sessions.

[redge]

YY wrote:
> Well the remote_viewer_C will be connected, but the server will KEEP ON MAKING new connection to the remote_viewer_C.

there no recursive or cascading connections of winvnc (separate thread per connection, no conflict)
winvnc.exe -autoreconnect -connect remote_viewer_A -connect remote_viewer_B -connect remote_viewer_C

i was reading somewhere this function was available or someone modified the code of winvnc and vncviewer to allow this function.

[Rudi De Vos]

It doesn't work.

Autoreconnect can only be used for one outgoing connection, it just doesn't work for multiple connections.
The origin af the option is "service_commandline" and there is only one commanline.
That you could inject it was a site effect, but doesn't work unless you keep in mind "only one"

Connections are initiated by the server (single instance) the server only can remember
one instance of autoreconnect, the last one used.

This can't be changed by replacing a lot of code (200-300 lines),
-inject code need to be replaced. ( this use int as ip address, need to be a sting)
-server need to span an instance for each injection
...
A lot of work and possible bugs.
It's better that we handle this together with ipv6 support, this require the int by string change to support it
anyway. 1097

Made some changes.

service OK ( support ip change of dnsname)
application OK (support ip change of dnsname)

inject to running winvnc ( running winvnc NOT started with commandline or service_commandline)
( no support ip changes, name is converted to ip and passed as int !!!)
winvnc.exe -autoreconnect -connect A
winvnc.exe -autoreconnect -connect B
winvnc.exe -autoreconnect -connect C
This tell to use autoreconnect to C, "only one" and you overwrite each time the previous value

If viewer A,B is oflline and C online, you now have 1 connection to C ( can take one minute to connect, timout on AB)
if viewer ABC online, you start 3 connections.
But the rule is to reconnect to C in case of a break.
if A oflline, then it reconnect to C ( 2X connection to C)

We can not fix this...in 10961

[redge]

thank for the clarification

ok for next release 1097

[YY]

inject to running winvnc ( running winvnc NOT started with commandline or service_commandline)
( no support ip changes, name is converted to ip and passed as int !!!)
winvnc.exe -autoreconnect -connect A
winvnc.exe -autoreconnect -connect B
winvnc.exe -autoreconnect -connect C
This tell to use autoreconnect to C, "only one" and you overwrite each time the previous value

If viewer A,B is oflline and C online, you now have 1 connection to C ( can take one minute to connect, timout on AB)
if viewer ABC online, you start 3 connections.
But the rule is to reconnect to C in case of a break.
if A oflline, then it reconnect to C ( 2X connection to C)

Rudi,

I was not complaining that ONLY ONE viewer (C) got autoreconnected. I do UNDERSTAND the latest autoreconnect command overwrite the previous value, and by design there is only one connection that can be kept autoreconnected.

The problem is: the server try to open NEW connection to the C's viewer for every 10 seconds, EVEN THOUGH the connection is already established. NOT ONLY 2X or 3X connection to C, but KEEP ON OPENING NEW CONNECTION, so C will have many many active connection windows (and keep on increasing), all from that server. You can easily repeat this bug with 10961 (Apr.26).


Here is the GOOD NEWS:

This bug is not existing in 10961 (Apr.30), and working properly with my test.

I hope this is not by chance, and is the result that you found out the problem and fix it.

[Rudi De Vos]

Indeed, the change was to block multiple waiting loops, they all connected to the same.
( In case vncviewer is not available)

The problem remain that when vncviewerA is online and you connect
A and B, autoreconnect is set to B. If viewer A breaks connection, it reconnect to B.
Can't fix that for now.

[YY]

Thanks for the explanation.
I think, finally, I understand the real nature of this bug.

The problem remain that when vncviewerA is online and you connect
A and B, autoreconnect is set to B. If viewer A breaks connection, it reconnect to B.
Can't fix that for now.

Yes I can repeat this situation with 10961 (Apr.30)

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.