Service Port Changes By Itself? (Nope; Repeater Crash)

[B]

I've been testing mostly in application mode, not enabling service mode until recently. I've used custom ports without issue.

It could be something I messed up in testing, but it seems that soon after I enabled the service mode, entering a custom ID number, the VNC server stopped responding on my previously working (in application mode) custom port numbers.

That is, after enabling ChunkVNC as a service, it responds ONLY on ports 5900/5800. I thought it was working properly at first -- so maybe when it periodically refreshes it reverts to using the default ports?

[supercoe]

Interesting, I guess some testing is involved here.

When installing the service InstantSupport writes to the ultravnc.ini

Code: Select all

service_commandline=-autoreconnect ID:4444 -connect example.no-ip.com:5900

Line 96 of InstantSupport.au3

Code: Select all

IniWrite( $TempPath & "\ultravnc.ini", "admin", "service_commandline", '-autoreconnect ID:' & $IDNumber & ' -connect ' & $RepeaterAddress )

Possibly the -connect isn't reading the port number?

[supercoe]

Still haven't tested yet but I think this might be the problem.
http://support1.uvnc.com:8080/index.php?section=16

What port number did you change to?

-connect host[:port]
-connect host <--- would connect to port 5500
Reverse connection,to if port < 1024 +5900 is added
host:1 -> port=5901
host:21 -> port=5921
-connect host[::port]
host::21 -> port=21
Special case: host[::port] =??? == request host and port

[B]

I used "444444" (six 4's).

Not sure if it's related or not, but later on, long AFTER I noticed this change in behavior, the repeater (running on the same target machine as the ChunkVNC server) crashed, with Windows calling it "distributer". The error may have related to it running as a service, but the repeater was NEVER running as a service on this machine. (I always executed it manually.) No viewer was connected, and nothing else at all was going on at the time of the repeater crash.

The Application Error log in Windows reads:

Faulting application repeater108.exe, version 1.1.0.4, time stamp 0x4afc3ce3, faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791a783, exception code 0xc0000005, fault offset 0x00060cf7, process id 0xf7c, application start time 0x01cab63a2fd20355.

[B]

I haven't yet restarted the VNC service, so if there's something you want me to try please let me know.

I've tried telnetting to it on my obscure port (no response) and on port 5900, which gets an apparently encrypted response (even though the repeater is no longer running). Port 5800 doesn't respond, but I guess that's normal as you don't have the JavaViewer enabled.

The default logging path (though not enabled) shows as c:\Program Files (x86)\ChunkVNC. I guess that directory gets created when you choose to run as a service? I didn't know that. I had assumed it would still be running out of its temp directory.

[supercoe]

Yea, installing as a service will make the program files directory.

So let me make sure we are on the same page as I still haven't done any testing.

1) You install as service with custom ports
2) You are unable to connect because the service reverse connection is trying to use port 5500 to the repeater?

[B]

1. Yes. And those custom ports were working okay at first, both before and immediately after right-clicking the system tray icon to install as service.

2. Not exactly.

I just realized the Chunk/WinVNC service is actually okay after all -- it was JUST the repeater slowly dying that must have screwed me up. Sorry! (When I failed to get a connection, I noticed the WinVNC service appeared to be listening on 5800/5900 as per its Admin Properties box, and since it did respond to telnet on 5800, albeit encrypted, and since the repeater was still running at the time, I mistakenly neglected to fully consider the repeater's role in the connection.)

With the same instance of the VNC service running, I just now restarted the repeater... and now telnetting to my custom obscure port works normally again, resulting in

RFB 000.000

<b>However</b>, things are still a bit screwy, since I can <b>not</b> actually connect back to the server. I'm getting "unknown authentication scheme" when connecting with my preconfigured Chunk viewer.

Here's my newer Repeater log:

Repeater for Rel1.0.8 of PcHelpware
socket() initialized
bind() succeded to port 56500
listen() succeded
socket() initialized
bind() succeded to port 5500
listen() succeded
Server added to list 444444
recv 39
accept() connection
Viewer added to list 444444
ID added 444444
ID viewer found 444444
ID viewer found 444444
ID viewer found 444444
ID viewer found 444444
ID viewer found 444444
connection closed by peer
Server Removed from list 444444

So apparently this all started when the earlier instance of the repeater was misbehaving prior to crashing, and for some reason things are still funky after restarting the repeater, and my <b>guess</b> is that this will all sort itself out when I reboot the machine. Again, sorry if I mistakenly blamed the VNC service earlier.

(Edit: More to the point, my subject premise that the "Service Port Changes By Itself?" is incorrect.)

[supercoe]

The winvnc service should be making a connection to the repeater on port 5500. I don't even know if the other ports are available for connection when it's setup for a reverse connection...

It appears that you've only changed the viewer port on the repeater, does this reflect what you've changed during compile?

[B]

Huh, the repeater / "distributer" app just crashed <b>again</b>. I wasn't even using it since my last test earlier this afternoon. WinVNC is still running.

Log tail:

2010/3/1 16:56:11 Transmitted: 0k
2010/3/1 16:56:12 2010/3/1 17:1:29 Transmitted: 0k
2010/3/1 17:1:34 2010/3/1 17:7:29 Transmitted: 0k
2010/3/1 17:7:39 2010/3/1 17:13:29 Transmitted: 0k
2010/3/1 17:13:41 2010/3/1 17:14:12 2010/3/1 17:14:12 2010/3/1 17:14:12 2010/3/1 17:14:12 2010/3/1 17:14:12 Transmitted: 0k
2010/3/1 17:14:12 Transmitted: 0k
2010/3/1 17:14:41 2010/3/1 17:15:25 2010/3/1 17:15:25 2010/3/1 17:15:41 2010/3/1 17:15:41 2010/3/1 17:15:41 Transmitted: 0k
2010/3/1 17:15:41 Transmitted: 0k
2010/3/1 17:15:42 2010/3/1 17:21:29 Transmitted: 0k
2010/3/1 17:21:29 2010/3/1 17:27:29 Transmitted: 0k
2010/3/1 17:27:34 2010/3/1 17:33:29 Transmitted: 0k
2010/3/1 17:33:41 2010/3/1 17:39:29 Transmitted: 0k
2010/3/1 17:39:41 2010/3/1 17:45:29 Transmitted: 0k
2010/3/1 17:45:41 2010/3/1 17:51:29 Transmitted: 0k
2010/3/1 17:51:34 2010/3/1 17:51:34 Transmitted: 0k
2010/3/1 17:51:41 2010/3/1 17:51:41 Transmitted: 0k
2010/3/1 17:51:42 2010/3/1 17:51:42 Transmitted: 0k
2010/3/1 17:52:11 2010/3/1 17:57:29 Transmitted: 0k
2010/3/1 17:57:41 2010/3/1 18:3:29 Transmitted: 0k
2010/3/1 18:3:34 2010/3/1 18:3:34 Transmitted: 0k
2010/3/1 18:3:41 2010/3/1 18:3:41 Transmitted: 0k
2010/3/1 18:3:42 2010/3/1 18:3:42 Transmitted: 0k
2010/3/1 18:3:44 2010/3/1 18:3:44 Transmitted: 0k
2010/3/1 18:4:11 2010/3/1 18:9:29 Transmitted: 0k
2010/3/1 18:9:41 2010/3/1 18:15:29 Transmitted: 0k
2010/3/1 18:15:41 2010/3/1 18:21:29 Transmitted: 0k
2010/3/1 18:21:41 2010/3/1 18:21:41 Transmitted: 0k
2010/3/1 18:21:44 2010/3/1 18:27:29 Transmitted: 0k
2010/3/1 18:27:34 2010/3/1 18:33:29 Transmitted: 0k
2010/3/1 18:33:39


That's how the last line reads... cut off. This is a bit saddening. Ah well.

[B]

The winvnc service should be making a connection to the repeater on port 5500. I don't even know if the other ports are available for connection when it's setup for a reverse connection...

Yeah, 5900 is listening as per netstat, but as I said it seems to be expecting an encrypted RC4 stream.

I just stopped the WinVNC service (via the system tray icon) and sure enough 5900 disappears from NetStat. I'm not sure why, or if, it's necessary that it be open when you're only doing a reverse connection to the repeater.

It appears that you've only changed the viewer port on the repeater, does this reflect what you've changed during compile?

Yes, that's correct. My two ports for ChunkVNC testing purposes have been 56500 and 5500.