My Feature Requests / Bug Reports

Rat · Post by **Rat** » 2010-02-04 06:12

Dear ChunkVNC People,

I have just spent almost 2 months trying to locate a reliable single-click remote support solution for one of my clients. I don't think I would be exaggerating to say that I have tried them all and have found them all wanting in some respect. Most of the commercial services fail to meet requirements because you are at the mercy of their bandwidth and connectivity limitations, since their repeaters are all running on their servers. I found that with the exception of CrossLoop none of the 'Free" hosted remote desktop solutions were of a commercially acceptable standard. This made me extremely wary of signing up for the paid versions for any of them. (BTW, what's the deal with CrossLoop, its just UltraVNC rebadged isn't it?)

I decided to re-address the problem by listing my requirements and applying a little out-of-the-box thinking. This resulted in me concluding that running the UltraVNC Repeater locally together with the client would be close to an ideal solution, if only I could get a re-branded single-click server running at the customer's end. It was while I was researching this problem that I belatedly stumbled across ChunkVNC, which to put it mildly was a revelation!

Not only had you solved all of my requirements in a single neat package, but you had done so in a clever and elegant open-source way.

So Kudos to you and my customer has promised that some free beer will soon be heading your way.

Now I would like to summarise my Feature request / Bug List Report for you:

Feature Requests:
1. Support for longer ID codes, (my customer would like to use their 10-digit telephone number).

Bug Reports:
1. I noticed I had to restart the Repeater between terminating a session and commencing a new one. This was on a Vista machine running both the Repeater and the InstantSupport applications locally. I received an error at the client end stating "Service running as an application", (not sure if this was relevant or not).

Questions:
1. Can I run multiple VNC Client Instances connecting to different InstantSupport servers through the same Repeater?
2. Can I re-compile using the latest versions of the UVNC Repeater, Server and Client binaries at any time? (if not please add this to the feature request list)
3. Confirm that the repeater can run reliably as a service.
4. How do I compile this with the latest version of AutoIt?

Cheers,
Keith.

supercoe · Post by **supercoe** » 2010-02-04 15:07

Rat,

Glad to see another happy user!

I'm confused as to why you've decided to run the repeater on the customers side? If you have already penetrated the firewall on their end you have no need for the repeater, just install UltraVNC normally. The idea of running the repeater in a fixed location is to get rid of port forwarding requirements for InstantSupport and the viewer since they both make outgoing connections.

Support for longer ID codes, (my customer would like to use their 10-digit telephone number).

You can change the restriction in ChunkVNC 3.1 (when installing as a service) by editing SRC\InstantSupport.au3 and compiling InstantSuport again.

Code: Select all

LINE: 93
CHANGE:   If IsNumber($IDNumber) and $IDNumber > 100000 and $IDNumber < 999999 Then
TO:       If IsNumber($IDNumber) and $IDNumber > 100000 Then

I noticed I had to restart the Repeater between terminating a session and commencing a new one. This was on a Vista machine running both the Repeater and the InstantSupport applications locally. I received an error at the client end stating "Service running as an application", (not sure if this was relevant or not).

This could be an issue with running InstantSupport on the same computer as the repeater, I'll look into it. I'm still not sure why you would choose to run InstantSupport on the same computer as the repeater, could you explain more?

Can I run multiple VNC Client Instances connecting to different InstantSupport servers through the same Repeater?

Yes, ChunkVNC is something I designed for my computer repair business so that I could support more than 1 customer at a time.

Can I re-compile using the latest versions of the UVNC Repeater, Server and Client binaries at any time?

Yes, this is exactly why I made it open source! Currently ChunkVNC is utilizing a special build of the UltraVNC server by pgmoney (sort of a prerelease of the next version)

Confirm that the repeater can run reliably as a service.

Other users are testing this now, check back to the forum often for updates.

How do I compile this with the latest version of AutoIt?

1) Download AutoIt http://www.autoitscript.com
2) Copy these files from the download to the SRC\Aut2Exe folder: Aut2exe.exe, AutoItSC.bin, upx.exe

Rat · Post by **Rat** » 2010-02-05 01:17

1) Download AutoIt http://www.autoitscript.com
2) Copy these files from the download to the SRC\Aut2Exe folder: Aut2exe.exe, AutoItSC.bin, upx.exe

Should I also copy all of the AutoIt Include files as well?

I'm confused as to why you've decided to run the repeater on the customers side? If you have already penetrated the firewall on their end you have no need for the repeater, just install UltraVNC normally. The idea of running the repeater in a fixed location is to get rid of port forwarding requirements for InstantSupport and the viewer since they both make outgoing connections.

Yes I guess I didn't explain that very clearly. I was doing my testing from Japan to a machine in Australia, (since I am temporarily out of the country). I am inside a Japanese provider's router which was blocking my server so for testing purposes I ran the repeater at the customer's end together with the InstantSupport.exe app so that I could see how it was going at their end. In any case they will eventually be running a Repeater service permanently on a server at their office so I needed to confirm that it was working correctly there.

In fact I am setting up several repeaters for this particular customer, one is runing as a service on a dedicated server back at their office and the others are running on their field techician's laptops so that they can have a faster connection speed by running the repeater locally and not having to route everything back through the office. Each machine running the repeater has a DynDNS update service also running to update a unique sub-domain so that they are all individually externally addressable at any time. Back at the office only the dedicated server has a port forward rule, so that there is no chance of a conflict when the laptops are connected to the office LAN. (Did I already mention just how neat a solution this ChunkVNC is?

)

I am now playing around with the AutoIt script to see how far I can go with the re-branding, (adding email buttons, links to the web, changing file names etc.).

BTW: You can add a Carriage Return or Line Feed character into an AutoIt script string literal like this:

"The first line of the string literal." & Chr(0x0A) & Chr(0x0D) & "The second line of the string literal.". (Useful for Message Boxes).

Possible Bug Report:
I also tried to compile the "InstantSupport.exe" file using a different Port number, (5900). This didn't appear to work with the repeater even though I also set the repeater's port to 5900.

Thanks Again,
Keith.

ps. Actually, ChunkVNC has helped me out twice, this AutoIt utility is also helping me to solve another unrelated problem

gilrim · Post by **gilrim** » 2010-02-05 14:30

with regards to entering a return in autoit, there are macros registered for that purpose..
http://www.autoitscript.com/autoit3/docs/macros.htm
@LF Line feed, Chr(10); typically used for line breaks.

so basically you do
"some text" & @LF & " more text on line2"

supercoe · Post by **supercoe** » 2010-02-05 14:43

Rat,

The newer compiler executables should be compatible with the older Includes but feel free to update those as well.

I'll look into the port 5900 issue...

gilrim, Rat,

This is my first programming adventure with AutoIt and I've been learning new tricks every day! Thanks to both of you for the MsgBox tip!

B · Post by B » 2010-02-09 15:37

Hi supercoe, and thanks for your efforts on ChunkVNC. Like Rat I've tried other solutions, including JDaus's SCPrompt, which I like quite a bit and is still very promising.

Please allow me to ask a few questions and make feature requests.

In my mind there are two distinct uses I'm interested in: (a) A pcAnywhere / LogMeIn / Terminal Server use model, wherein a software agent sits ready full-time to be accessed by a remote consultant like me. (b) A one-off model where a random user might need assistance, to anywhere, and from anywhere.

It seems to me that SCPrompt addresses scenario (a) a bit better than ChunkVNC, and that ChunkVNC addresses scenario (b) better.

1. Is that a fair comparison and description?

2. Are you two working together as some of the previous comments hinted?

3. Why, exactly, does ChunkVNC use the random-numeric-session-ID model of identifying target computers? I understand the need to readily distinguish among unpredictable on-demand stations, but what's wrong with alphanumerics, which I always consider MUCH easier to remember and deal with (for me and for end users)? How about a station name, DNS name, user name, or maybe numeric IP address? Are the numerics a limitation of the Repeater?

4. Is it possible to use a user-specified ID string WITHOUT doing the "Install as service", but rather upon starting the InstantSupport app? If we're stuck with numerics, I do prefer the "enter your phone number" method over a random ID.

5. Shouldn't the InstantSupport app in the system tray have a right-click option other than "Install Service" -- specifically, an Exit option? It seems the only way to close the app cleanly is to exit via the restored window and the wait popup.

6. Do I read your "tea leaves" correctly that the next version is going to provide a list and clickable interface more similar to GoToMyPC or LogMeIn, where a list of available PC targets is provided to the Viewer owner? (This is something I'd very much want -- having to know particular random session ID numbers in advance, especially if the target PC is unmanned, is very inconvenient.)

7. Not clear on the status of the OSX and Linux versions -- is there a quick "To/From" compatibility matrix for server and viewer support?

8. I think it should be a bit more straightforward to alter the port settings in all 3 components. Currently there are different ways for each of the 3 apps.

9. During my first two "compiles" I got a lot of errors, apparently due to existing installations of UltraVNC on my machine. I had similar trouble at first corralling SCPrompt into working properly for me. It seems UltraVNC can't resist accessing the registry and/or existing installations, no matter how portable people try to make it?

10. Any idea how compatible this is with other versions of VNC? In my experience UltraVNC has been largely incompatible with TightVNC, ChickenoftheVNC, etc., which has kept me from relying on it.

What I want in most cases is something a lot like LogMeIn, but that runs on a repeater I trust and control, is multiplatform, and is open source. ChunkVNC seems like it's on the right track towards that, and I thank you for it...

-- B

supercoe · Post by **supercoe** » 2010-02-09 16:23

In my mind there are two distinct uses I'm interested in: (a) A pcAnywhere / LogMeIn / Terminal Server use model, wherein a software agent sits ready full-time to be accessed by a remote consultant like me. (b) A one-off model where a random user might need assistance, to anywhere, and from anywhere.
It seems to me that SCPrompt addresses scenario (a) a bit better than ChunkVNC, and that ChunkVNC addresses scenario (b) better.

1. Is that a fair comparison and description?

I've never used SCPrompt so I don't know how to compare them. ChunkVNC is going after the same idea as TeamViewer, you have quick support that can install permanently.

2. Are you two working together as some of the previous comments hinted?

Currently the only people working on ChunkVNC are myself and guinness, although others have made suggestions with code.

3. Why, exactly, does ChunkVNC use the random-numeric-session-ID model of identifying target computers? I understand the need to readily distinguish among unpredictable on-demand stations, but what's wrong with alphanumerics, which I always consider MUCH easier to remember and deal with (for me and for end users)? How about a station name, DNS name, user name, or maybe numeric IP address? Are the numerics a limitation of the Repeater?

The UltraVNC repeater only supports numeric ID's. The next release will deal less with ID numbers.

4. Is it possible to use a user-specified ID string WITHOUT doing the "Install as service", but rather upon starting the InstantSupport app? If we're stuck with numerics, I do prefer the "enter your phone number" method over a random ID.

I think this would ruin simplicity as I don't believe the customer should have to do anything but run the app.
You could add this feature yourself by editing \SRC\InstantSupport.au3.

5. Shouldn't the InstantSupport app in the system tray have a right-click option other than "Install Service" -- specifically, an Exit option? It seems the only way to close the app cleanly is to exit via the restored window and the wait popup.

This has been added to the next release.

6. Do I read your "tea leaves" correctly that the next version is going to provide a list and clickable interface more similar to GoToMyPC or LogMeIn, where a list of available PC targets is provided to the Viewer owner? (This is something I'd very much want -- having to know particular random session ID numbers in advance, especially if the target PC is unmanned, is very inconvenient.)

Lurk much?

lol
Yes, the next release is going to focus on removing the need to know the ID number, I've basically made my own server that can pass commands between InstantSupport and ChunkViewer.

7. Not clear on the status of the OSX and Linux versions -- is there a quick "To/From" compatibility matrix for server and viewer support?

OSX InstantSupport is considered a functional beta, Linux has been put on hold.
I won't be creating a ChunkViewer for Linux/OSX in the foreseeable future, so using a third party viewer is currently the only way.

8. I think it should be a bit more straightforward to alter the port settings in all 3 components. Currently there are different ways for each of the 3 apps.

I agree that this should be "standardized" but the compiler adjusts the ports. If you choose to do it by hand I should make you work a little, right?

9. During my first two "compiles" I got a lot of errors, apparently due to existing installations of UltraVNC on my machine. I had similar trouble at first corralling SCPrompt into working properly for me. It seems UltraVNC can't resist accessing the registry and/or existing installations, no matter how portable people try to make it?

Interesting, I'll have to try this. The only time the compiler is involved with UltraVNC is when it opens the viewer to delete settings and create the rc4.key.

10. Any idea how compatible this is with other versions of VNC? In my experience UltraVNC has been largely incompatible with TightVNC, ChickenoftheVNC, etc., which has kept me from relying on it.

Compatibility relies on whether the vnc viewer supports the UltraVNC repeater.
Look at: http://www.karlrunge.com/x11vnc/ssvnc.html

What I want in most cases is something a lot like LogMeIn, but that runs on a repeater I trust and control, is multiplatform, and is open source. ChunkVNC seems like it's on the right track towards that, and I thank you for it...

You're welcome.

The project is only a few months old and has taken off very quickly. Stay tuned for 4.0 as it will add much of the functionality you are looking for.

B · Post by B » 2010-02-09 16:54

Hey, great reply! Thanks so much for all your explanations.

4. Is it possible to use a user-specified ID string WITHOUT doing the "Install as service", but rather upon starting the InstantSupport app? If we're stuck with numerics, I do prefer the "enter your phone number" method over a random ID.
I think this would ruin simplicity as I don't believe the customer should have to do anything but run the app.
You could add this feature yourself by editing \SRC\InstantSupport.au3.

Your judgment call, of course, but I think making someone record and recite back a random numeric string is less "simple" than having them type their phone number. Your model seems to assume that both the server user and the viewer user are in front of their respective machines at the same time AND on the phone with each other, which is not always the case. FWIW.

Thanks for the link; I never heard of Enhanced TightVNC.

Oh, and a (rather basic and obvious) tip for fellow users -- you can and should generate TWO versions of InstantSupport.exe, one for local network users, using a locally resolvable name or IP address for the repeater, and one for external users accessing the repeater as routed in through your firewall. Many routers or firewalls do not handle "hairpinning" gracefully, so that, when operating locally, attempts to reach internal resources by their external DNS names will fail.

One last thought; someone else mentioned securing access to the repeater from the general public; I think some sort of access control is going to become essential as the project grows. (This is a big part of the reason I prefer to use customized, relatively obscure port numbers rather than VNC defaults.) Thanks again; I'm really looking forward to the new version. [It has been a continual surprise to me that no GoToMyPC/LogMeIn workalike exists in the open source world. It's about time!]

-- B

supercoe · Post by **supercoe** » 2010-02-09 17:57

B,

Your model seems to assume that both the server user and the viewer user are in front of their respective machines at the same time AND on the phone with each other, which is not always the case.

I do assume a method of communication (phone, chat, etc...) between the customer and support agent.
In my business someone calls for remote support and that's why I've designed it this way. I tell them to download InstantSupport and read me the ID number.

If someone were to run InstantSupport and send you the ID number later it will remain connected to the repeater until you are ready to connect with the viewer.

Could you explain more about your situation where you won't have communication with the customer?

attempts to reach internal resources by their external DNS names will fail.

Some routers don't support WAN loop-back, I'll see if I can make it easier to get around this.

securing access to the repeater from the general public

Currently the only way to do this is by not forwarding the viewer port (5901) to the repeater but you will lose the ability to connect a viewer from outside your LAN.

I agree that more security needs to be put in place but we are at the mercy of the UltraVNC devs on this one.

Don't forget to read the FAQ some of your questions have already been answered there.

B · Post by B » 2010-02-09 20:03

I'm thinking of more long term remote control needs, where a client (for example, a trusting family member) wants to have me able to remote in at will, whether or not they're there. I'm also thinking of longer term telecommuting situations a la pcANYWHERE or Citrix terminal server. I'm also thinking of situations where you tell someone "hey, get this executable off my web site" or send it via e-mail, and then you try to control their PC later, when they may not even be at their desk. Or, alternatively, you may be busy and are not at your viewer station when the person gets around to installing the applet. Couple all that with my dislike for the numbering scheme and I think you begin to see my point? That goes towards what I mentioned earlier about SCPrompt and LogMeIn. This is particularly at issue if both parties are busy or if you're supporting more than one person.

Sure, I suppose people could convey the session ID by leaving voice mail or sending e-mail messages (if their mail is working) but it seems less straightforward than (a) letting them install at their leisure, regardless of where you are, (b) having them tag their machine with an easily known number, such as their phone number, and maybe some day an alphabetic string, and (c) being able to view the machine at YOUR leisure. (Obviously it won't be that loose when you're trying to get on and off a client machine quickly in order to protect their privacy or be paid for a certain period of work.) Yes, I realize I can accomplish most of this manually by rolling individual IDs by hand in the .EXEs before distributing.

Regarding the loopback, I don't see that as a big problem -- people who have the issue, like I do, can easily roll two versions of the .EXE. I just renamed one "LocalInstantSupport" and one "RemoteInstantSupport."

For securing, I suppose one could require SSH or VPN to access the Viewer port but leave the Server port wide open. (I guess this would probably be done on an individual basis, not by your project.) That could work, though it's still a bit of a hassle for a roaming tech. Hmm.

Yup, thanks, I viewed the FAQ. By the way, minor nit there, the path you illustrate to the ultravnc.ini file is inaccurate; I guess you changed it at some point, as it's currently \SRC\InstantSupport_Files .

supercoe · Post by **supercoe** » 2010-02-09 20:23

B,

Thanks for elaborating, now it's clear to me what you're looking for.
You're going to like ChunkVNC 4.0

stay tuned to the forum for a release.

Good eye catching the FAQ typo, I'll be updating it.

B · Post by B » 2010-02-09 23:13

Very cool. I'm eager to see it.

Another gripe/observation that might help out others: the reserved ranges [ "100000 to 200000 will connect without encryption. ( For Mac InstantSupport )" ] were causing havoc with my testing until I realized that was why I was having trouble connecting -- I was using "123456" as a test for the service version, and I don't think it plays well in Windows:

Connection failed - Invalid protocol !

Possible causes:

- You've forgotten to select a DSMPlugin and the Server uses a DSMPlugin
- Viewer and Server are not compatible (they use different RFB protocols)

Using the same setup (and restarting the service) with an ID of "333333" worked fine. My apologies if this has already been discussed. I appreciate the need to distinguish the OSX range, but perhaps those limits and considerations should be mentioned on the window that prompts for an ID number for the service?

While we're on the subject, can the TeamViewer ad on that error screen be removed via ultravnc.ini ?

Another question, if you don't mind. I gather that the InstantSupport.exe is truly standalone, containing everything necessary including the RC4 keys. (And that you do this by unpacking UltraVNC to a temp directory.) Conversely, the remote ChunkViewer.exe installation will ONLY work properly if the entire Viewer directory is copied (specifically the Bin directory), as indicated in the instructions. Is that correct? Is it possible to bundle the Viewer similarly? I'm looking for ease of deployment on BOTH sides if possible.

Also, I now realize that my earlier suggestion about Local and Remote versions is incomplete -- because ChunkViewer is recompiled too, and it relies on chunkviewer.ini, which ALSO gets changed. So we "Viewers" have to be a bit more careful. Really, as it currently works, I'll need to have separate "Local Viewer" and "Remote Viewer" directories, each containing a copy of Chunkviewer and each with a different Bin/Chunkviewer.ini . Hmph. Ah well.

Thanks again...

Edit: Holy smokes. I just realized I can't leave InstantSupport running 24/7; authentication's off by default, and the RC4 key is shared(?). Is the key randomized during installation? Do all InstantSupport servers I create /distribute have the same RC4 key (they'd have to) and does that mean those stations/users can "View" each other if they use ChunkViewer? I'll have to read the FAQ again.

supercoe · Post by **supercoe** » 2010-02-10 00:42

Another gripe/observation that might help out others: the reserved ranges [ "100000 to 200000 will connect without encryption. ( For Mac InstantSupport )" ] were causing havoc with my testing until I realized that was why I was having trouble connecting -- I was using "123456" as a test for the service version, and I don't think it plays well in Windows:

You are the first one to find this bug, it has since been patched but not released.
The only mention of this is in the 3.1 changelog:
* Updated InstantSupport Windows to only use ID's 200000 to 999999
* Updated ChunkViewer so ID's 100000 to 200000 will connect without encryption. ( For Mac InstantSupport )

While we're on the subject, can the TeamViewer ad on that error screen be removed via ultravnc.ini ?

Preferably we would never see the error message but I don't mind supporting the developers of UltraVNC. If you would like it disabled edit the source code to include -disablesponsor when launching viewer.exe.

I gather that the InstantSupport.exe is truly standalone, containing everything necessary including the RC4 keys. (And that you do this by unpacking UltraVNC to a temp directory.) Conversely, the remote ChunkViewer.exe installation will ONLY work properly if the entire Viewer directory is copied (specifically the Bin directory), as indicated in the instructions. Is that correct? Is it possible to bundle the Viewer similarly? I'm looking for ease of deployment on BOTH sides if possible.

You must copy the entire viewer directory as ChunkViewer only launches the UltraVNC viewer located in the Bin directory.

Also, I now realize that my earlier suggestion about Local and Remote versions is incomplete -- because ChunkViewer is recompiled too, and it relies on chunkviewer.ini, which ALSO gets changed. So we "Viewers" have to be a bit more careful. Really, as it currently works, I'll need to have separate "Local Viewer" and "Remote Viewer" directories, each containing a copy of Chunkviewer and each with a different Bin/Chunkviewer.ini . Hmph. Ah well.

Or have a router that properly supports NAT loopback

This is a tricky one to get around, I'll be adding options to the compiler for people in your situation.

I just realized I can't leave InstantSupport running 24/7; authentication's off by default, and the RC4 key is shared(?). Is the key randomized during installation? Do all InstantSupport servers I create /distribute have the same RC4 key (they'd have to) and does that mean those stations/users can "View" each other if they use ChunkViewer? I'll have to read the FAQ again.

It is a preshared key, potentially anyone can extract the rc4.key from InstantSupport.exe and use that to connect to another computer using the same key.

The encryption is more of a way to stop sniffing of the network traffic it is not meant as a replacement for properly securing a computer that will be running vnc as a service.

B · Post by B » 2010-02-10 01:03

So it depends, as always, on how we use this. In your original conception, viewer and server would both be on line, in communication with each other, and in ultimate control of their respective sessions.

But if I try to use ChunkVNC in more of an always-on service mode, I need to be much more aware of the security implications (leaving a PC on with a non-passworded remote control agent and shared encryption key).

That being said, do you think you should expose the UltraVNC authentication options during setup (or maybe you already have and I missed it)? If you'd rather not, can you give me a quick recipe for doing it without breaking anything?

Thanks yet again for your quick responses.

supercoe · Post by **supercoe** » 2010-02-10 01:40

B,

The concept of ChunkVNC is to remain as simple as possible. I could expose many options that UltraVNC provides but I choose to pick what I think is best and go from there. The reason I released the source code is so people can modify it for their needs, if you need to change the security options feel free to do so.

Really it boils down to that (to me) security doesn't exist, you can only ward off potential hackers by making it as difficult as possible. At version 3.1 the security isn't great by any means but at least encryption exist. Guinness and I are working hard on the next version and we have plenty of security ideas to add in the future but at this point in time they just haven't been implemented into a release yet.

The best security you can have is to not forward the viewer port (5901) to the repeater. This way no one could connect a viewer to your repeater outside of your LAN.

I'm glad you like the project and your input has been great, but please understand that it's impossible for me to add every feature requested while maintaining a simplistic vision.

B · Post by B » 2010-02-10 14:26

Sure, no problem. I understand how projects can go nuts trying to accommodate everyone, and I'm just one tester.

I'll have to noodle with it myself a bit. I was hoping to avoid learning AutoIT.

Thanks as always for your prompt replies.

-- B

fredfred · Post by **fredfred** » 2010-02-10 14:37

1. Can Autoit the viewer also into single exe which can put on the web for download by different support personal ?

2. How to change the size of windows of the ChunkVNC ?

3. Place the ID on top of a Picture or Image?

Thanks
________
Vodun (voodoo) forum

supercoe · Post by **supercoe** » 2010-02-10 14:52

B wrote:I'll have to noodle with it myself a bit. I was hoping to avoid learning AutoIT.

I'm usually in this boat too, I used to write all of my apps in VB.Net because I just loved how easy it was and plenty powerful for my needs. I choose AutoIt when I was planning this project and just learnt it as I went. Their forums are awesome and the help file is fantastic with examples.

Really I've never been happier with a programming language. It completely blows away VB.net for ease of use and is much more powerful.

supercoe · Post by **supercoe** » 2010-02-10 15:02

fredfred,

1. Can Autoit the viewer also into single exe which can put on the web for download by different support personal ?

This feature has been requested quite a bit, I'll be adding this to a future release. In the mean time just .zip the viewer folder after compiling.

2. How to change the size of windows of the ChunkVNC ?

The source code is very well documented, either install AutoIt or use Notepad++ to edit the .au3 files.

3. Place the ID on top of a Picture or Image?

This should only depend on the draw order.

B · Post by B » 2010-02-12 23:55

Hi again. Some more tips and observations I've encountered in trying to extend or secure ChunkVNC.

1. First, to possibly shed some light on the weird registry versus .INI nature of UltraVNC that I mentioned above, [topic=14937][/topic] may be helpful, at least a little.

2. In separating the "Local" and "Remote" setups I've mentioned (for local networks that won't hairpin a public DNS name), I noted I could no longer use the Compiler after I (intentionally) renamed the regular Viewer directory -- the compiler just hangs. In other words, for people like me maintaining separate "LocalViewer/LocalInstantSupport" and "RemoteViewer/RemoteInstantSupport" setups, you'll need to recreate the regular "Viewer" directory if you ever want to recompile.

3. I can NOT seem to require password authentication, even after enabling the tray icon, mucking with the temp directory's UltraVNC.ini, changing the encrypted password, and adding the "AuthRequired=1" option to the [Admin] section. No matter what, reverse UltraVNC connections (such as those to the repeater in ChunkVNC) don't want to listen to a password. In fact, it seems that about the ONLY version of VNC that will allow passwords on reverse connections may be x11VNC as described at http://linux.die.net/man/1/x11vnc

This kind of stinks, for my purposes at least (leaving the InstantSupport VNC server connected to the repeater full time). I'd rather not add an SSH tunnel or VPN or other front-end authentication. In fact, with this limitation, I might as well create unique RC4 keys for EACH target server, which would approximate unique passwords, but would be hellish to manage on the viewer side, I'd imagine.

Anybody have a way around this? (It would be good enough for me to just have the UltraVNC server require a password!)

4. Anyway, on a tangent, while researching I came across one interesting roll-your-own alternative to ordinary old UltraVNC SC:

http://www.runpcrun.com/create_your_own ... t_software

supercoe · Post by **supercoe** » 2010-02-13 01:35

1. First, to possibly shed some light on the weird registry versus .INI nature of UltraVNC that I mentioned above, [topic=14937][/topic] may be helpful, at least a little.

You'll have to do some digging here to figure out what registry keys are being used/created. According to that link only the .ini has been used since version 1.0.2

2. In separating the "Local" and "Remote" setups I've mentioned (for local networks that won't hairpin a public DNS name), I noted I could no longer use the Compiler after I (intentionally) renamed the regular Viewer directory -- the compiler just hangs. In other words, for people like me maintaining separate "LocalViewer/LocalInstantSupport" and "RemoteViewer/RemoteInstantSupport" setups, you'll need to recreate the regular "Viewer" directory if you ever want to recompile.

It's clearly stated in the installation guide that you shouldn't change/move the viewer folder.
I'll add some file checks to the compiler...

NOTE: You can copy the viewer folder (after compiling) to all of the computers that will be providing support.
Make sure to copy the viewer folder, it must not move out the the main folder or compiling will fail!

3. I can NOT seem to require password authentication, even after enabling the tray icon, mucking with the temp directory's UltraVNC.ini, changing the encrypted password, and adding the "AuthRequired=1" option to the [Admin] section. No matter what, reverse UltraVNC connections (such as those to the repeater in ChunkVNC) don't want to listen to a password. In fact, it seems that about the ONLY version of VNC that will allow passwords on reverse connections may be x11VNC as described at http://linux.die.net/man/1/x11vnc

Set a password via the server "Admin Properties" window and remove the rc4.key. The viewer will prompt for you to enter a password to connect.

This kind of stinks, for my purposes at least (leaving the InstantSupport VNC server connected to the repeater full time).

If you are really that freaked out about security just do what I said before and don't forward the viewer port (5901) to the repeater. This will ensure that nobody could connect a viewer to the repeater outside of your LAN.

4. Anyway, on a tangent, while researching I came across one interesting roll-your-own alternative to ordinary old UltraVNC SC:
http://www.runpcrun.com/create_your_own ... t_software

I don't understand how this is relevant to ChunkVNC? Many people have made SC type programs using many different vnc products.
This program requires installation before running, can't be installed as a service, doesn't support UAC.....

krash_control · Post by **krash_control** » 2010-02-15 14:36

Hi

I've had a problem running the client on some computers that already have WinVNC installed, though it works fine on others.

There is an error that comes up that the service is already running, is there a way that maybe you could give the user the option to stop the existing service until the session is complete? Then when the InstantSupport.exe is closed, the service is sent a start command again?

supercoe · Post by **supercoe** » 2010-02-15 14:50

krash_control,

Yes, currently there isn't any code in place to see if a vnc session is already active. Mostly because of time restraints and the amount of testing involved with various vnc software. I'll be sure to implement this in the future.

B · Post by B » 2010-02-15 23:38

supercoe wrote:3. I can NOT seem to require password authentication, even after enabling the tray icon, mucking with the temp directory's UltraVNC.ini, changing the encrypted password, and adding the "AuthRequired=1" option to the [Admin] section. No matter what, reverse UltraVNC connections (such as those to the repeater in ChunkVNC) don't want to listen to a password. In fact, it seems that about the ONLY version of VNC that will allow passwords on reverse connections may be x11VNC as described at http://linux.die.net/man/1/x11vnc

Set a password via the server "Admin Properties" window and remove the rc4.key. The viewer will prompt for you to enter a password to connect.

You are good; thanks. First I didn't quite follow your directions and just disabled the DSM plugin in Admin Properties. I kept getting "Microsoft Windows... VNC server for X64/win32 has stopped working" crash boxes when attempting to connect. Then I listened to you, and deleted the RC4 key in the Viewer's directory AND I had to still disable the DSM Plugin checkbox in Admin Properties... and then it worked as you said!

But it does throw up a warning about unencrypted connections (You have specified an encryption plugin, however this connection is unencrypted! Do you want to continue?), apparently because the viewer was still trying to use the DSM...

So then I tried deleting the MSRC4Plugin in the Viewer/Bin directory too. And something even stranger happened. First I got a popup reading "You have specified an encryption plugin, however this connection is unencrypted! Do you want to continue?"... and then it connected me fine, but WITHOUT prompting for the password! Curious thing, this VNC.

Anyway, I'm reticent to block the Viewer port, because I really like the "from anywhere, to anywhere" nature of your project. (What would be great some day is a 2-way web services version -- as I'm sure you know, the original VNC had a terrific little Java web server.)

I can't wait to see the new ChunkVNC.

B · Post by B » 2010-02-16 00:22

Also, I've just noodled with SCPrompt again, and it really is well developed. You might want to take a look at it for comparison/borrowing/inspiration.

[topic=14809][/topic]

It already has repeater support, service support (not sure about UAC), predefined port IDs, multiple named connection profiles, and the ability for an end user (server) to manually specify a port ID. (It also supports direct connections.) On the down side it keeps turning on mouse sonar. Arrgh.

It's intended more as a "roll your own SC packages" thing than Chunk is, but I think the only features ChunkVNC would add are the randomized port IDs and the bundling of the repeater.

I don't know if it's being quite as actively developed as this project at the moment. But for what it's worth.

Rat · Post by **Rat** » 2010-02-16 00:37

Well speaking as a developer and someone who's tested all of these other approaches in depth... ChunkVNC is easily the best and most flexible approach. This is because of the inspired decision to use AutoIt to "wrap" up UltraVNC's server, client and repeater.

Quite literally I can do whatever I want and customise as much as I want just by doing some simple AutoIt scripting... have a look at my "Fork" example I posted earlier in this forum if you want a good example of what I'm talking about.

Cheers,
Ratty

>//o

B · Post by B » 2010-02-16 00:46

Yes, I saw it, and wondered how much supercoe would be able to reuse.

Nice job, and thanks for sharing your "reluctant fork" efforts.

But I'm pretty sure SCPrompt is written in AutoIT too! So there's a lot of opportunity for code sharing/collaboration if the developers care to. Either way, I'm glad both (or is that all 3) projects exist...

B · Post by B » 2010-02-16 04:30

I suspect some of my security concerns might be addressed by the SSL VPN formerly known as SSL-Explorer.

http://sourceforge.net/apps/trac/openvpn-als/wiki

This would be the kind of seamless layer I'm looking for. In the past it has included VNC modules, although I don't know how well it works with repeaters.

Sorry if this is considered a tangent; to me, decent security is essential if this is to ever serve more than the tinkerer audience.

supercoe · Post by **supercoe** » 2010-02-16 14:29

Rat,

You've hit the nail right on the head! You are my target market

B,

I've tried SCPrompt and other projects on this forum when I was looking for a remote support program for my business. They all worked well but each one had it's own problems. The biggest thing I wanted was the "bleeding edge" vnc server for maximum performance/compatibility and (at the time) the other projects were using older servers.

VPN or SSH is definatly an option, but at least for now I prefer the simplicity of not having to set up another server. People have enough problems figuring out the repeater as is.

As Rat has stated, ChunkVNC really is a developers tool, the customization is unlimited when you open up the SRC files. This is why I made the package so anyone could modify the source to suit their needs.

ltctech · Post by **ltctech** » 2010-02-28 11:24

Another thing that I found useful is to change the encoder settings for the viewer.
The default uses Hextile coding I think, which although is good quality, it's slow.
I made the viewer use Tight instead and it works quite well.

Code: Select all

ShellExecute(@ScriptDir & "\Bin\vncviewer.exe", "-proxy " & $RepeaterAddress & " ID:" & $IDNumber & " -noauto -encoding tight
 -compresslevel 9 -quality 9 -keepalive 1 -dsmplugin MSRC4Plugin.dsm -disablesponsor")

UltraVNC

My Feature Requests / Bug Reports

My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports

Re: My Feature Requests / Bug Reports