Halting autoreconnect

[laurent]

I'm using the UltraVNC software to remotely support a few computers. Given the nature of the internet, and that the vnc client crashes from time to time when tampering with scaling and whatnot, I've setup all computers to autoreconnect their reverse-connected servers.

This is perfect, as, once a user clicks "Connect to support", I have a lasting VNC session that will survive a lot of problems.

However, I can't find out how to terminate that! I thought that by going to the server computer, right-clicking the icon and selecting "Kill all clients" would terminate me and not reconnect, but it does reconnect.

From what I've read so far, it appears the only solution is to close my "vnc viwer in listening mode" for a few minutes. Fine, but sometimes I'm connecting to more than one client computer at once, then I can't really kill all the vnc viewers I run in order to close one session...

I there a way to terminate the autoreconnected sessions? Perhaps a kill button somewhere "Disconnect, and this time, I mean it!" ? Maybe a secret switch i could give to winvnc.exe /dont-not-do-reconnect-anymore ?

Thanks

[laurent]

15 minutes later I re-opened my viewer and it re-connected to me. This is becoming is a problem

[B]

Why not just close the VNC server on those machines?? Right click the tray icon and either exit or stop the the service. Or go into services.msc and stop it there. Am I missing something?

[laurent]

How will my client re-establish a connection the next time they need it?

[B]

If it's installed as a service, they can just reboot.

[laurent]

Production system, can't be rebooted...

[B]

So they can just restart the service, or relaunch WinVNC from the Start menu or desktop, or run a script, or about a bazillion other ways of restarting the WinVNC service. Or you could turn off reconnect and they could toggle it back on. Or you could even temporarily block their IP addresses at your router, or maybe configure your VNCViewer to reject them. Or do something with the scheduler.

I just don't see the problem here? What is it you'd <b>like</b> to happen?

[laurent]

Ah, restarting the service. Now that's a great idea. I assume that by the time I press the restart button in windows control panel, I'll be kicked out and the service relaunched, without a request to connect pending. That sounds promising, and I'll try it.

I know there's a bazillion ways to do it, I came here to ask for suggestions as to which would be the best.

Blocking the IP: that would work, but after 15 minutes the client still reconnected. It seems I would have to block most of my clients for long periods of time, that can become cumbersome.

Turning off reconnect: That's what I'm trying to do, turn off reconnect. The clients launch a shortcut "winvnc.exe -autoreconnect -connect me.com", so this, once launched, can't be "turned off", which is the essence of the problem.

Next time I get a minute on a client pc, I'll give a try to the service restarting suggestion.

Thanks!

[B]

Well wait a sec then; if they're manually or automatically launching a <b>shortcut</b> then I guess you're not running a service at all. So to stop the polling you'd just make them exit the server from the system tray (it's called "close" in TightVNC; don't have UVNC handy at the moment). And then they'd relaunch your shortcut when necessary....

[laurent]

Ah yes, funny story. I tried to make it work "this way" back when I initially setup these computers. For the life of me, I could not have the VNC program connect to a listening server if the service was not running. I have no idea why, as my assumption is that manually launching "winvnc.exe" should launch a user-mode server, but it didn't. I remember it complaining about not finding a service. I eventually gave up, installed the service, un-clicked the listening ports so that it's not listening to anything, and then used my shortcut successfully.

Perhaps instead of trying to resolve this auto-reconnect issue, I should take a new look at fixing the won't-work-without-service problem, and fix that instead.

Thanks for you help.

[B]

You're welcome. Yeah, I guess you should try it that way again -- I've never had that particular problem, although I've used TightVNC more than I have UltraVNC. Your assumption was correct. In fact, if you disable the service right now, your current shortcut <b>should</b> still work fine, as far as I know.

UAC can get in the way though.

[YY]

as my assumption is that manually launching "winvnc.exe" should launch a user-mode server, but it didn't. I remember it complaining about not finding a service.

You need to start the vncserver in application mode with the "-run" option, as below:

Code: Select all

winvnc.exe -autoreconnect -connect xx.xx.xx.xx:5500 -run

[B]

What happens if -run isn't used? What is it doing, trying to run as admin? I'm pretty sure it's not going to run as a service by default, right?

[YY]

"if -run isn't used?"
The simple answer is the winvnc.exe will not be started and making the reverse connection, just as laurent mentioned.

To explain why, that's a long & complex story .....
A simple explanation is this option telling the winvnc.exe to start the vnc engine by itself, and then execute the command (-connect xx.xx.xx.xx:5500, etc).

This option was created about 2 years ago (If my memory is correct, Rudi added this option per the request of JDaus). Unfortunately, all those related threads were removed from the forum, and this option is not well documented at the offical site.

[B]

Thanks for the reply, but I'm still not sure I understand. Are you saying that:

a. If the -run is omitted, then the command will work -- if and only if the service is already running. If the service is not running, the command fails completely.

b. If the -run is used, WinVNC will start with the listed parameters, whether or not a WinVNC service was already running.

Is that it?

[YY]

a. If the -run is omitted, then the command will work -- if and only if the service is already running. If the service is not running, the command fails completely.

Almost as what you said, but more accurate: "if and only if the UVNC engine is already running".
The UVNC engine can be started if a single command "winvnc.exe" is executed by the user, or the UVNC started in service (in fact, i.e. using a system a/c to run the winvnc.exe).

So in laurent's case, if not using the "-run" , he/she can achieve the same result with following script:

Code: Select all

winvnc.exe
winvnc.exe -autoreconnect -connect xx.xx.xx.xx:5500

or, using the command I suggested: winvnc.exe -autoreconnect -connect xx.xx.xx.xx:5500 -run

or, using the method as what laurent done, ie:
- Have the winvnc.exe running as service:
- execute the command: winvnc.exe -autoreconnect -connect xx.xx.xx.xx:5500

b. If the -run is used, WinVNC will start with the listed parameters, whether or not a WinVNC service was already running.

If the WinVNC service was already running, i.e the UVNC engine had been running, using the "-run" option will return an error message "Another instance of WinVNC is already running", as the "-run" will try to start the UVNC engine as well.

[B]

Beautiful. What you just wrote should be part of the documentation. Thank you.

I would think a slightly different twist would be valuable too, an option to pass desired parameters an existing instance OR start a new one... but I guess one could accomplish that just by trying both in order (that is, first with "-run" and then again without it).

I wonder how TightVNC handles this; I'm too lazy to look at the moment....

...Edit: Well, I looked,and they don't seem to want to tell me. These TightVNC command line options don't seem to be described anywhere!

winvnc [-run] [-kill] [-service] [-servicehelper] [-connect [host[:display]]] [-connect [host[::port]]] [-install] [-remove] [-reinstall] [-reload] [-settings] [-defaultsettings] [-killallclients] [-shareall] [-shareprimary] [-sharearea WxH+X+Y] [-sharewindow "title"] [-about] [-help]

Looks great, but what do they all do? Ultra seems to have far fewer options, but at least some of them are documented.