Failed to Connect to Server !

[vicspain]

I am not having much luck in getting ChunkVNC to work -

Environment:
- Windows 7/64b
- Motorolla Router - model vt2142 (Supplied by Vonnage VOIP)
- Comcast Cable
- UltraVNC Current Stable Version 1.0.8.2
- ChunkVNC - Version 3.1
- Anti-Virus - MS Security Essentials

- Forwarded 5500, 5900 and 5901 to win 7 pc 192.168.15.5
- Open port check site verifies these ports are open
- set all of the vnc ports to public in the windows firewall

To test:
- Started the repeater from 192.168.15.5
- connected to an outside PC running XP using Remote Desktop. When I run InstantSupport.exe, I see Server added to list 954883 followed by recv 39 on the repeater log of my Win 7 machine.

- I then run chunkviewer.exe on the Wind 7 support machine and enter the connection ID
- Fails with message "Failed to Connect to Server"

I hope that I've supplied all of the information necessary to solve this. The process seems simple enough but for me it's not working. I also had someone else run the InstantSupport from their computer (outside my lan) with same results.

I really would appreciate some help!

Vic

[B]

You didn't actually mention running the repeater?

Do I assume that you are running the repeater continuously on the machine at 192.168.15.5, and that the "Server added to list" is from the repeater's window?

Instructions are at http://chunkvnc.com/installationguide.html

If so, everything you're describing sounds right to me.

Are you using the same ChunkViewer generated from the "compile" stage that created the InstantSupport.exe?

It might just be that, when connecting locally, your public address fails to route back inside. This happens to me too -- the local router refuses to redirect youroutsideaddress to 192.168.15.5.

I just compiled two different versions (Viewer/InstantSupport pairs) for local and remote use. One embeds the local address for the repeater, and the other embeds the public address for the repeater.

If you have a local DNS server at your disposal, that's another way around the problem.

To test whether this is in fact your issue, just try using ChunkViewer from outside your LAN. Then you'll be accessing your repeater via its public address, just as your InstantSupport test was doing...

[topic=17181][/topic]

[topic=18002][/topic]

[vicspain]

[quote="B"]You didn't actually mention running the repeater?

Sorry - Yes I've started the Repeater from 192.168.15.5

Do I assume that you are running the repeater continuously on the machine at 192.168.15.5, and that the "Server added to list" is from the repeater's window?

Yes - that is correct

Are you using the same ChunkViewer generated from the "compile" stage that created the InstantSupport.exe?

Yes

It might just be that, when connecting locally, your public address fails to route back inside. This happens to me too -- the local router refuses to redirect youroutsideaddress to 192.168.15.5.

I just compiled two different versions (Viewer/InstantSupport pairs) for local and remote use. One embeds the local address for the repeater, and the other embeds the public address for the repeater.

B, Are you saying just run the Compiler.exe and insert my local ip address 192.168.15.5 to generate everything? And then are you saying to run tjhe repeater and InstantSupport.exe from 192.18.15.5?

If you have a local DNS server at your disposal, that's another way around the problem.

I don't but I'm testing on a remote PC using Remote Desktop. Will this be a problem. I have tested outside without Remote Desktop and get the same results.

Thanks B,

Vic

[B]

Yes, but you also need to be careful to keep your original directory structure in case you need the other version. (Or you could just recompile again.)

My posts in the linked threads go into more detail as to what I did. Basically I copied/renamed things after each compile so I have in my ChunkVNC_3_1 directory the following subdirectories:

Viewer (this needs to be there, and holds the last compiled version)
Remote Viewer (contents of Viewer after compiled for for remote access)
Local Viewer (contents of Viewer after compiled for local access)

and the following files:

LocalInstantSupport.exe (compiled for local access)
RemoteInstantSupport.exe (compiled for remote access)


The selected viewer directory needs to be copied in its entirety to whatever machine will be doing the viewing.

The answer to your question is "yeah, sorta". The point is that both the clients and servers (ChunkViewers and InstantSupports) need to see the repeater. A machine running INSIDE your LAN needs to see the repeater at its 192 address (maybe). A Machine running OUTSIDE your LAN needs to see the repeater at its public (and port forwarded) address. You don't run the repeater and InstantSupport "from" a particular IP address. It's a matter of how the client and server reach the machine.

You won't be changing the repeater, or port forwarding, at all.

Remote Desktop isn't a problem. What you CAN try is using that Remote Desktop ability to start a ChunkViewer session, as I suggested above. If you really <b>do</b> have the same problem I did, then ChunkViewer should work just fine when launched from the outside (that is, when launched from a remote machine to which you've connected via Remote Desktop).

[vicspain]

B,

I probably don't have the same problem as you because my local testing after trying to connect it waits for the longes time and thenb errors out with "Connection Failed - Error reading protocol Version".

But also as I've previously said I'm getting "Failure to Connect to Server" on both an outside machine along with a remote desktop connection to an outside machine.

BTW - UltraVNC works correctly connecting to any of my local machines without using ChunkVNC.

Vic

[B]

No, I've gotten that error a lot too.

From what I read earlier above I thought you had tried InstantSupport (the server) running on remote machines, but that all your viewer attempts had been from inside your LAN. Sorry if I misread you.

Does UltraVNC connect to your repeater successfully?

Are you shutting down UltraVNC when you're running the ChunkVNC versions? (Of course ChunkVNC is just a wrapper around a copy of UltraVNC, and you can't run them both at the same time on the same ports.)

[vicspain]

B,

OK - I got it working and here is what I did.

1. ran the compiler.exe and gave it my external ip address

2. modified the ip address in the chunkviewer.ini, changing the ip address from the remote to my local (192.168.15.5)

3. Ran the InstantSupport from 2 different remote computers, 1 using remote desktop and the other not. both worked successfully.

Great - Now my question is Why? I know the compile step rebuilds the ini file but it never asks for the internal ip address. Is it supposed to work this way. I'm working with my brother on a totally different lan and his results are the same as mine so I don't think it's the router. Seems more like a bug.

Any ideas?

Thanks,

Vic

[B]

By changing the ChunkViewer.ini you accomplished the same thing as "recompiling" and copying the Viewer directory (the way I did it).

The compile certainly asks for an address - of the repeater. It then uses that address (a) for the ultravnc.ini inside the InstantSupport.exe package and (b) for the chunkviewer.ini in the Viewer directory.

The problem is that using the EXTERNAL public IP address (or a DNS name pointing to it) just doesn't work on some internal networks. It's missing a feature called DNAT (Destination NAT). Your internal network and the PCs on it don't know anything about its public address. You ask for yourpublicIPaddress, and your PC knows it's not on the local network. It hands the request off to the router (its next hop / gateway). Your particular router is refusing to redirect that internal traffic right back inside where it arguably belongs. Technically it would have to rewrite your packets.

Just try it. Try pinging your repeater by its public IP address or its public DNS name. From inside your LAN it will in all likelihood fail.

So that's why your viewer never connected -- it could never even find the repeater.

This would be no different if you were trying to run a web server on that machine. Your local machines could not access it by its public IP address or domain name.

Come to think of it, you shouldn't be able to run InstantSupport.exe inside your network either. It too should fail to connect to the repeater.

It's not a bug; it's a difference in router behavior (implementation). (It certainly has nothing to do with VNC or any other software.) When you know it exists you can work around it.


http://iptechtalk.wordpress.com/2009/09 ... rkarounds/ looks like a pretty good summary for the Cisco environment. We're pretty much talking about his Scenario 3.

[vicspain]

The compile certainly asks for an address - of the repeater. It then uses that address (a) for the ultravnc.ini inside the InstantSupport.exe package and (b) for the chunkviewer.ini in the Viewer directory.

Yes, I know but you only enter the external address not the internal address. It only asks for a single ip address and I believer that is supposed to be the public ip address.

The problem is that using the EXTERNAL public IP address (or a DNS name pointing to it) just doesn't work on some internal networks. It's missing a feature called DNAT (Destination NAT). Your internal network and the PCs on it don't know anything about its public address. You ask for yourpublicIPaddress, and your PC knows it's not on the local network. It hands the request off to the router (its next hop / gateway). Your particular router is refusing to redirect that internal traffic right back inside where it arguably belongs. Technically it would have to rewrite your packets.

Just try it. Try pinging your repeater by its public IP address or its public DNS name. From inside your LAN it will in all likelihood fail.

Yes, I underand that and I've never been able to test things like this from inside my lan. However, I would have thought that accessing it using a remote PC that port forwarding would take over and hand it off to the particular ip the Port had assigned

It's not a bug; it's a difference in router behavior (implementation). (It certainly has nothing to do with VNC or any other software.) When you know it exists you can work around it.

I can certainly live with this, I just thought it was a bug since 2 different lans and 2 different routers both experience the same symptoms. Perhaps a mention in the documentation would help as at least from my perspective it seems quite common (2 out of 2).

Thanks for the help - much appreciated and I think it's a great litlle product and it's fast!

Vic

[B]

You're correct, it asks for a single address, because that's all the Viewer and Server will use. If you were only using ChunkVNC within your LAN, you'd give it an internal address or name.

If you were only using ChunkVNC with Viewers and Servers OUTSIDE your LAN, you'd give it an external address or name.

But in our mixed use cases, you have to deal with the router's limitation.

Where we agree is that it might make sense for supercoe to mention this in the documentation somewhere. I do know, however, that he strives to keep the instructions as simple as possible.

For the same reason, I doubt he'll want to automatically generate a "Local" and "Remote" set of viewer/server pairs, as I have, but based on asking for both the public and private IP addresses of the repeater during the compile.

Then again, that's not a bad idea!

[vicspain]

For the same reason, I doubt he'll want to automatically generate a "Local" and "Remote" set of viewer/server pairs, as I have, but based on asking for both the public and private IP addresses of the repeater during the compile.

Personally, I wouldn't generate 2 sets because I like probably most want this for supporting remote customers. Just a mention in the documentation that because of "Router Limitations" you may have to modify the ChunkViewer.ini file by replacing the public ip address with the private. This ini file would be customized for each support person.

On the other hand if someone is supporting both internal and external I think is all that needs to be done is document the procedure. I really don't think a program modification is necessary. It's not that big of a deal to have to modify the ini file.