I think there went something wrong:- if both options are enabled + hit reload button -> launcher seems to be in a "online-check-loop" (it iterates through the server and starts again from the beginning...)- if only "scan on refresh" is enabled + hit reload button -> launcher doesn't check the online status- if only "auto 5 minutes" is enabled: sometimes (not always) it scans at launcher-start...it does not seem to scan every 5 minutes (not sure about that)(for the short test: I changed the settings and restartet the launcher...then observed the above described)

I think it should be that way:"auto 5 minutes" = 1 -> scan online-status at launcher-start and every 5 minutes"scan on refresh" = 1 -> scan online-status on reload-button (if reload button is hit and "auto 5 minutes" = 1 perhaps timer should be reset to freshly countdown 5 min to the next online-check)?

Issues repeater:* Initial repeater scan seems to be not done. All servers red after program start.* After manual scan all server go green/red and then the first server in list blinks green-grey/grey-green. All other servers stay green/red although all servers are online.

Repeater is configured global not per .vnc.

Issues viewer:* still or again the viewer is searched "\vncviewer.exe" if no explicit viewer is configured. Correct search would be ".\vncviewer.exe"

yes, clear, green-red means repeater ok + id not found. So, couldn't be a login problem into the GUI otherwise it should stay a double red-red screen or a single red screen.

I assume check of IDs fails. Or isn't completed at all because of the hanging and blinking first item. We use extensive comments. A possible reason?GUI is not available from Internet. I agree, without debug information it's not possible to dig deeper. A debug log file would be enough. No need of a window, my opinion...

Found it.I typed the repeaters password the first time and every following tries directly on first program start into the global input field.After typing the password one time while being "logged in" = using the gear wheel it works.

Seems to be a bug on first start that password isn't encrypted or with empty passphrase or what ever.

Yes, of course I don't expect a magical decryption without password But I did enter the password. So it must work.As you can see in my description: after application restart and entering the "login" password (= the password used to encrypt decrypt passwords) it does not work.Once "logged in" and use the gear wheel to re-enter repeaters password it does work. Until restart. Even if the "login" password (= the password used to encrypt decrypt passwords) is of course entered.

So, this is not by design. This is a bug. I assume we just misunderstood each other.

Yep, that was what i was saying...a bug.We encrypt the web password , before the encryption password was entered...in source.

It was tested with the default password, then you don't need to enter a password on startup. But entering a password it fail, because we already decrypted the web password with a empty encrypt password on start, and not after entering the encryption password.

Now we have the gui passwd set, using the "encrypt passwd"1) start launch2) enter "encrypt passwd", you notice a grayed gui passwd field, this is normal because before we knowthe "encrypt passwd" we are unable to decript this entry3) Check if the scan proper show the user/passwd used to web login

Did it already as you described. Of course I did because it's not that heavy to type 2 passwords correct.I assumed that the system is in an inconsistent state because of the previous bug.So I did it several more times. And I did a reset, did a start over with an empty uvnclaunch.ini. After restart it is still not working.

But I noticed, that every time I restart the application and I do a "login", uvnclaunch.ini is rewritten and rpass changes. This must not happen!This is at least one reason. The password is kind of alternating every time I restart.

I also noticed that even if I encrypt every time the same password it's not always the same rpass string.Therefore I assume it's something like a pointer/memory errors, or encryption of already encrypted, or previously wrong decrypted and then reencrypted, or whatever. Something goes horrible horrible wrong.Possibly more a pointer error. Why? Reason: You seem to encrypt in AES block mode. We use a short password. Always the same during testing. So rpass use to have some bytes, then a lot of zeros and one single different byte at it's end. But I noticed, sometimes not. There are bytes where have been zeros always before. Even though the always same encryption password and repeater password is used.

Don't get me wrong, but with this error pattern it doesn't make sense to do more tests or to dig deeper.

Found:Using debug OKUsing release a empty field is not empty, looks like some lib error, but fixedIf debug behave different then release we can test forever.

Found another nasty bug in thre repeater.When the launcher checked the status, existing connection break.Fixed, buffers need to be reinit after a loop else our repeater alive test is like connecting the last connected ID againand this kick the previous.

hmm...I'm a little bit irritated: there is something really weird happening when I try to store a password using the Edit-Menu of the launcher. It looks like (a part of) the password is used as the target Host on connecting to a server.

This is what I did:- start launcher, enter password- Context Menu -> Add -> enter a Hostname in "VNC-Server" -> Save-Button -> enter Hostname as Filename -> OK- (wait until Server-Tree is rebuild...why does that take that long?)- double-click the new created server -> instantly password-request popup: enter password -> OK -> Connection is up.=> Thats OK, but now try to store the password in the launcher- select the new created server -> context menu -> Edit -> enter Password in Password-Field -> Save- double-click the server...only "VNC Viewer Status" is shown, no password-request...=> looking at the "VNC Viewer Status" it shows the last part of the Connection-Password as "VNC Server"-Host!?=> looking at the DebugConsole: the online-check ist contacting the right Hostname (server is shown "online" in the tree)

Argh, while writing I realize the problem: If the Connection-Password has a "blank"/"space character" in it -> the part after the blank is used as Server-Host (according to the "VNC Viewer Status"). Only the online/offline check uses the right Hostname...

EDIT: I can't see any fault in the *.vnc files; the "blank"-bug seems to be in the launcher / variable-handling.EDIT2: I see...you pass the password on the commandline:"...\vncviewer.exe" -password PASS WORD -config ".\uvnc\hostname.vnc"...it need to be:"...\vncviewer.exe" -password "PASS WORD" -config ".\uvnc\hostname.vnc"

tried it: you can use " in the password (e.g. pass"word )...connection succeeds as long as you manually enter the password in the viewer request window, but I couldn't figure out how to pass such a password to the viewer using the commandline (" needs to be escaped?).

Passing the password in clear text is not that secure, is it? (Other applications could just snoop the commandline of the process...)Perhaps it would be a little better to implement a second password switch in the viewer, which accepts a default-encoded password (like passwd / passwd2 in UltraVNC.ini)...then pass the password from launcher to viewer using this new commandline parameter. Other benefit: no problems with special characters like blanks, double quotes, ...

Most applications don't allow ' " & . Peopls we use them have bad luck, we don't support it.a " " need to be supported as people sometimes use a sentence as pass.

ultravnc.ini, vnc can encrypt/decrypt the password with a buildin key.This is uncesure, it just hide the passwd for dummy's.This how the current vnc password is done.

The launcher has a single password that's used as encryption key for blowfish encryption.This encryption encrypt all passwords web passwd in uvnclaunch.inivnc password using an extra entry in the .vnc file, only used by the launcher.You will see it as mspasswd in, the .vnc file

The problem is that you can only decrypt the password with the provided encryption you enter on start.vncviewer doesn't know it, so he can't decrypt the passwordIf I pass this password to the viewer, the master password is visable via the commandline, so same issue.

Rudi De Vos wrote:Most applications don't allow ' " & . Peopls we use them have bad luck, we don't support it.a " " need to be supported as people sometimes use a sentence as pass.

Fair enough! (I fully understand it...and would argue the same way.)

password handover launcher -> viewer: Yes, I see the problem (that's why I wrote "...a little better..." - it would still neglect the security aspects), but sadly I'm not a professional software developer...just don't know what a suitable solution could be.

Created a few vnc-connection files and now the Launcher crashes on start (after entering the password) -> found the culprit: if the filename-length exceeds 31+4 chars the launcher crashes with 0xc0000409. (If you need a crash dump, let me know.).\uvnc\1234567890123456789012345678901.vnc -> OK.\uvnc\12345678901234567890123456789012.vnc -> crash=> Could you please raise that limit to the max. of 255 chars? (Filename is the only Description Field of the launcher)

And a question: Why does a manual "reload servers" take more than 20 seconds (tree is invisible in that time; console only says "DEbug started")? (settings: scanrefresh=0 + scan5=0)

Have problems here. Initially after "login" it takes 5 seconds until any check happens. But when it happens, it fails. As you can see attached. If I press refresh immediately after this, it works. As you can also see.