Modified repeater (Source code)

[vcka]

Does linux version supports auto reconect from server side?

[shadowfax]

That's right... If you wish to use encryption the easiest way to go is using an SSH tunnel. Let me explain...

In order to select the repeater ID through the password, the repeater acts as a standalone server during the hanshaking phase up to the last stage where the client and server exchange their initialization messages. Encryption takes place at an earlier phase. Precisely it takes place at the authentication phase used to exchange (In this case) the repeater ID.

Since the viewer can connect before the server has connected there is no way to know if the server will allow encryption. On the other hand the repeater authenticates to the server as "No authentication required", therefore the server sends unencrypted data. Since the authentication schemes are hidden through the repeater the only possible way to allow encryption is to implement the encryption at the repeater (for example, adding VeNCrypt support) BUT the repeater would slow down since one of the sides (Server-Repeter or Viewer-Repeater) could allow this authentication scheme but the other side wouldn't allow it; therefore the repeater should decrypt incoming data, look at the other point and reencrypt it or send it unencrypted depending on its capabilities. IMHO this would downgrade the repeater's performance and therefore I don't think it's worth implementing encryption... If someone thinks otherwise I'll take a look and I could add a precompiler condition to accept the most commonly used encryption scheme.

I think the best way to go would be adding a VPN tunnel for the viewers (Not exposing the viewer port to the internet as a security measure)... and the server connections can be tunneled through SSH if encription is desired.

Openminded to other suggestions or ideas on how to face this "problem".

[shadowfax]

vcka, not yet

When one of the connections closes (Server or viewer side) both ends get disconnected to free the repeater slot. Correct me if I'm wrong, but what you are looking for is: if the server get's disconnected from the repeater -maybe because of bad coverage when connected through a mobile network- that it will reconnect to the repeater but keeping alive the viewer. Is that correct?

If it is so, I'm planning to make this happen but I have to implement something like the "timer" of the original version to free idled connections. Once this is done, modify slightly the code so the viewer doesn't get disconnected if the server exits (Already made some code changes to make this easier to achieve once the timer has been implemented).

[YY]

Hi! shadowfax,

Very happy to discover your modified repeater. Your idea is great. (extend the listening port of the uvnc server with its mode II operation, so that overcome the limitation of a port-forward-not-allowed router)

New update...

The new version starts to differ from the original version.....

For your 1st released repeater, when a server connected, the repeater will log with a message of:
Add_server-list(): Server added with ID .............

(and so does the viewer)

For this new release, this feature is gone.
Why remove this feature, I think this message is very useful for monitor purpose of the operation of the repeater.

The repeater ID is deleted if it hasn't been used for 5 minutes.

In my test, the repeater will not remove a viewer/server after 5 minutes, even they never meet & connect their counter party with the matching ID, but some users may like this feature. It will be best if this timeout can be configurable.

[B]

Openminded to other suggestions or ideas on how to face this "problem".

Have you thought about opening a second door into the repeater, one that accepts registrations via https? I realize that what makes your idea so cool is that it works with all VNCs out of the box without additional layering, but a repeater ID reservation process via http or https would be convenient as an adjunct.

It would need its own logic and timeout, of course, but it would mean that some of the initial encryption worries would disappear (nothing would be in plain text) and viewer and server could themselves use any encryption or none at all.

[ Of course what I'm secretly wanting is full repeater management capability, viewing and picking from available attached targets by ID and name, etc. in GoToMyPC/LogMeIn style. I think the ChunkVNC dev is working on at least some of that, using the x11vnc Perl repeater. ]

[shadowfax]

First of all thanks for your suggestions and I'm glad you find the repeater usefull. Hope we all get the repeater working and stable enough. The only way to do this is by testing it so I really appreciate you are trying the repeater so it can be tested in a much more efficient way. The more people using it it will be easier to trap any possible bug.

For your 1st released repeater, when a server connected, the repeater will log with a message of:
Add_server-list(): Server added with ID .............

(and so does the viewer)

For this new release, this feature is gone.
Why remove this feature, I think this message is very useful for monitor purpose of the operation of the repeater.

The verbose output will be back, probablly defining the verbosity level. One of the reasons I didn't place them back in was a dessign error. On the first version I was converting the encrypted data to HEX in order to show the debug information and I kept the hexed string in memory. This took 32 bytes of memory per ID. Now I only store the encrypted string so the memory usage for repeater ID has been cut in half (Plus I only mantain one structure instead of two, so it is even lower). If the first character is a byte with value equal to 0. It won't show up, so I have to bring back the HEX value (Although it isn't stored). I hope to add even more verbosity to make sure everything is doing what it is supposed to do and giving the hability to the user to set how verbose the repeater should be.

In my test, the repeater will not remove a viewer/server after 5 minutes, even they never meet & connect their counter party with the matching ID, but some users may like this feature. It will be best if this timeout can be configurable.

That's right... That feature was implemented in a previous version where I sticked closelly to the original VNC repeater but, once started to focus it another way, I took away the "timer" thread. I want to bring the timer back into the application but I've been looking over for the main functionality to start working as it is suppoed to be before adding more code to the application. Right now the application is structured in different files and I think it is about time to get it back in... However, I'm still thinking on creating a new file called "Threading" and creating a WIN32 and a POSIX file for it (Loading one or the other depending on the platform)... Winsock vs BSD sockets is easilly managed through precompiler conditions but the differences between processes and threads between Linux an Windows are a bit more complex. So right now I'm a bit uncertain on which way to go first...

Have you thought about opening a second door into the repeater, one that accepts registrations via https?

Yes, I've been thinking about it but I keep bumping into problems. The only way this could be functional is by creating an HTTPS server that would bring up an interface whith the IDs and create an AJAX client for the different IDs. The AJAX client should take into consideration a mobile client probably doesn't have a keyboard and place a softkeyboard on screen when the images are shown. However I'm not proficient enough in C/C++ for image manipulation to make this work.

If you only reserve the ID through the HTTPS interface some new problems come to live. One comes up from the user experience as the user needs two connections to establish the VNC sessions... However, as you stated, it would solve some problems like the 8 character limit of the VNC password, the output of the connecting viewer would be clearer, there could be encryption (Although I think the VNC server should be modified to acomplish this as I think it always connects with no authentication), etc...

But there are also other considerations from the security point of view. One of the biggest threats I've considered is the Internet Service Provider Proxies. Some users, even mobile device users, are being routed through proxies which could lead to two people with the same IP address. If the ID is reserved to an IP address this could lead into collisions where two users reserve a diferent ID but one of them could a session that was not requested (Entering the other user's request). Further more, if the servers are connecting with no authentication (UltraVNC seems to be connecting with no authentication for example) it could make an attacker using your same proxy gain access to those servers. Right now this is harder since he could resend the repeater ID (if sniffed) but as the slot is in use he wouldn't gain access. I know there are ways to retrieve the "real" address in the HTTP protocol but I would have to stick to the public IP address as there is no way of retrieving the real ip address through the RFB protocol. Another problem is that some mobile networks change proxies and, therefore, the IP address could be changed between the HTTPS reservation and the VNC login (Haven't seen this so often but I've read of things like this happening with PHP sessions that store the public IP address for security). This is the main points why I always bumb against a closed door... Due to security concerns the VNC session should be established right away. Therefore the only reasonable way I've found to do it through HTTP is an AJAX VNC viewer.

However, if you wish encryption on the VNC connections, establishing an SSH tunnel would do the job and it wouldn't imply new security threats. There are quite a lot of document on SSH port forwarding to make the repeater stand behind SSH... And there is also quite a lot of documentation on how to make an application talk SSH. In fact, one of the projects I have in mind right now is making my own HelpDesk VNC Server stripping things away from the VNC Server and adding SSH capabilities for the reverse connection. What I'm really up to is compiling the repeater on an openfirmware router (Probably OpenWRT or DD-WRT) and implement StrongSwan and XL2TP (Don't know yet if this is possible without hardware hacks) that would allow me access to the private network and to the Viewer port of the repeater. On the other hand install OpenSSH and tunnel the reverse VNC server through SSH against the repeater.

[B]

Great response; thanks!

On those Linux-based routers, at least, couldn't you just run x11vnc, which <b>itself</b> can act as a repeater?

http://www.karlrunge.com/x11vnc/faq.html#faq-reflect

I may have more to add as I try to further digest what you've said.

[YY]

@shadowfax,

Thanks for your detail explanation.

Just another two suggestion:
1. Able to run the repeater as service.
2. Make sure no [topic=15187]Nagle Algorithm delay[/topic] issue.

[vcka]

vcka, not yet

When one of the connections closes (Server or viewer side) both ends get disconnected to free the repeater slot. Correct me if I'm wrong, but what you are looking for is: if the server get's disconnected from the repeater -maybe because of bad coverage when connected through a mobile network- that it will reconnect to the repeater but keeping alive the viewer. Is that correct?

If it is so, I'm planning to make this happen but I have to implement something like the "timer" of the original version to free idled connections. Once this is done, modify slightly the code so the viewer doesn't get disconnected if the server exits (Already made some code changes to make this easier to achieve once the timer has been implemented).

I mean, then session ends, both ends gets disconnected. But if server is running whit option -autoreconnect it must reconnect with same ID-password. In this case it doesn't. Maybe it's because server gets wrong disconnection string?

[shadowfax]

On those Linux-based routers, at least, couldn't you just run x11vnc, which <b>itself</b> can act as a repeater?

Disn't know it could run as a repeater... Does it allow MODE-II (ID based reapeating)? I guess, in case it allows it, it would still need to be modified in order to allow this kind of hack for a standard client such as iPhone clients and so on.

Just another two suggestion:
1. Able to run the repeater as service.
2. Make sure no Nagle Algorithm delay issue.

On the next version it will be possible to disable the Nagle Algorithm. Some sites say disableing the Nagle Algorithm could lead to some unexpected troubles therefor it will be optional.

In order to enable/disable the Nagle algorithm (and considering your request for the repeater to run as service), I've included a configuration file. I don't wish to work with the registry in order to keep most of the code platform independent. However, in order for the application to run as a service there should be changes to the output and the repeater should be able to write to a log file. Therefore don't expect this feaure on the next version, but I'll try to build it in a future.

By the way, since I find the encrypted ID not really usefull and I can't find a way to get the clear ID from the viewer, I've changed the string when a Viewer or a server connects to the repeater in order to show the IP address. Something like "Viewer connection accepted for 127.0.0.1". It will be released on the next update.

I mean, then session ends, both ends gets disconnected. But if server is running whit option -autoreconnect it must reconnect with same ID-password. In this case it doesn't. Maybe it's because server gets wrong disconnection string?

The "-autorecconnect" feature is implemented on the VNC Server. It should work with the repeater. My testing environment is as follows: Windows Vista running UltraVNC Server 1.0.8.2, UltraVNC Viewer 1.0.8.2, Repeater running on Windows Vista (or repeater running on a virtual machine with GNU/LINUX Debian 5)... Also testing from iPod Touch with a free, view only, VNC viewer. The "-autoreconnect" feature of VNC Server is working.

Maybe the problem arises from the VNC Server you are using or maybe it is a bug in a previous version of the repeater (Server socket not closing up cleanly). If it is a bug of the repeater it will be solved on the next version as I'm getting no trouble with it.

[vcka]

Thanks, i was using older version. Now every thing lucks good.
PS. One more problem on linux:
32242 root 20 0 52396 1020 800 R 100 0.0 8:42.25 repeater

repeater is using 100% of cpu, it doesn't matter if its empty or is used by someone.


HERE WE GO!
Two servers and two viewers connected, then one viewer disconnects i got this error:
ERROR: do_repeater(): Writting ClientInit error.
*** glibc detected *** ./repeater: double free or corruption (fasttop): 0x0804d158 ***
======= Backtrace: =========
/lib32/libc.so.6[0xf7d2b04c]
/lib32/libc.so.6(cfree+0x85)[0xf7d2d085]
./repeater(__gxx_personality_v0+0x297)[0x8048e7b]
./repeater[0x804a38e]
/lib32/libpthread.so.0[0xf7f36195]
/lib32/libc.so.6(clone+0x5e)[0xf7d9aefe]
======= Memory map: ========
08048000-0804c000 r-xp 00000000 09:02 4777118 /home/vcka/1/repeater
0804c000-0804d000 rw-p 00004000 09:02 4777118 /home/vcka/1/repeater
0804d000-080b0000 rw-p 0804d000 00:00 0 [heap]
f4b00000-f4b21000 rw-p f4b00000 00:00 0
f4b21000-f4c00000 ---p f4b21000 00:00 0
f4cbd000-f4cbe000 ---p f4cbd000 00:00 0
f4cbe000-f54bd000 rw-p f4cbe000 00:00 0
f54bd000-f54be000 ---p f54bd000 00:00 0
f54be000-f5cbd000 rw-p f54be000 00:00 0
f5cbd000-f5cbe000 ---p f5cbd000 00:00 0
f5cbe000-f64bd000 rw-p f5cbe000 00:00 0
f64bd000-f64be000 ---p f64bd000 00:00 0
f64be000-f6cbd000 rw-p f64be000 00:00 0
f6cbd000-f6cbe000 ---p f6cbd000 00:00 0
f6cbe000-f74bd000 rw-p f6cbe000 00:00 0
f74bd000-f74be000 ---p f74bd000 00:00 0
f74be000-f7cbe000 rw-p f74be000 00:00 0
f7cbe000-f7e0a000 r-xp 00000000 09:02 18235413 /emul/ia32-linux/lib/libc-2.7.so
f7e0a000-f7e0b000 r--p 0014b000 09:02 18235413 /emul/ia32-linux/lib/libc-2.7.so
f7e0b000-f7e0d000 rw-p 0014c000 09:02 18235413 /emul/ia32-linux/lib/libc-2.7.so
f7e0d000-f7e11000 rw-p f7e0d000 00:00 0
f7e11000-f7e1d000 r-xp 00000000 09:02 18235690 /emul/ia32-linux/usr/lib/libgcc_s.so.1
f7e1d000-f7e1e000 rw-p 0000b000 09:02 18235690 /emul/ia32-linux/usr/lib/libgcc_s.so.1
f7e1e000-f7e40000 r-xp 00000000 09:02 18235418 /emul/ia32-linux/lib/libm-2.7.so
f7e40000-f7e42000 rw-p 00022000 09:02 18235418 /emul/ia32-linux/lib/libm-2.7.so
f7e42000-f7f25000 r-xp 00000000 09:02 18235693 /emul/ia32-linux/usr/lib/libstdc++.so.6.0.10
f7f25000-f7f28000 r--p 000e2000 09:02 18235693 /emul/ia32-linux/usr/lib/libstdc++.so.6.0.10
f7f28000-f7f2a000 rw-p 000e5000 09:02 18235693 /emul/ia32-linux/usr/lib/libstdc++.so.6.0.10
f7f2a000-f7f30000 rw-p f7f2a000 00:00 0
f7f30000-f7f43000 r-xp 00000000 09:02 18235416 /emul/ia32-linux/lib/libpthread-2.7.so
f7f43000-f7f45000 rw-p 00012000 09:02 18235416 /emul/ia32-linux/lib/libpthread-2.7.so
f7f45000-f7f47000 rw-p f7f45000 00:00 0
f7f54000-f7f58000 rw-p f7f54000 00:00 0
f7f58000-f7f59000 r-xp f7f58000 00:00 0 [vdso]
f7f59000-f7f76000 r-xp 00000000 09:02 18235407 /emul/ia32-linux/lib/ld-2.7.so
f7f76000-f7f78000 rw-p 0001c000 09:02 18235407 /emul/ia32-linux/lib/ld-2.7.so
fffe9000-ffffe000 rw-p 7ffffffea000 00:00 0 [stack]
Aborted

[shadowfax]

Thank you vcka. Since I was only testing with a single connection I didn't notice that huge memory leak (double free or corruption). The slots where messing thing up. I think this error has finally been fixed.

The CPU usage is due to the main application loop, shich is empty. I don't know which way to go right now. There are several options:

• Make one of the listening threads the application loop.
• Adding the timer method here. It would keep the application skeleton clean but it would delay the application exit.
• Make the main application loop check if one of the threads (Listening sockets) has exited although no exit signal was submited. In this case it would restart the closed thread. This shouldn't happen, but maybe it would be nice to make sure.

New features

• Configuration file. The file is named "vncrepeater.conf" and should be located on the application path under Windows or inside /etc/ under Linux.
• You may disable the Nagle Algorithm inside the configuration file.
• Fixed the memory bug reported by vcka. (Thanks again)
• Reports the connection IP when a server/viewer connects to the repeater.

[vcka]

Testing new one under linux. The problem - then i start vncserver and viewer for the first time, i got this log on repeater:
UltraVNC> do_repeater(): connection closed by server.
UltraVNC> Repeater thread closed.
And the server doesn't reconnect automaticaly.

[shadowfax]

Sorry about that...

I made some further changes and the issue has been fixed. Thank you again vcka for reporting this bug. Hope the new version works as expected.

I've also changed to non-blocking sockets (Making internals closer to the VNC Server). I've also changed some socket options, and made some changes to attains better compatibility between Winsock and Berkley Sockets.

[vcka]

Thanks, but linux archive is somehow corrupted
It is zero length.
I compiled by my self. But ...
UltraVNC> Server connection accepted from 1x.2x.2x.x6
ERROR: zero bytes read
UltraVNC> server_listen(): Reading authentication type error.
UltraVNC> Viewer connection accepted from 127.0.0.1.
In previous version every thing was ok. It would be very nice if there where a posibility for more verbosity.
If i close viewer every thing is ok : UltraVNC> do_repeater(): connection closed by viewer.
But then closing server the socket is not released.

[shadowfax]

That's weird, could not reproduce this error on Windows (The virtual machine's network interface has gone mad and I can't debug the LINUX version). What steps did you follow to get this error?

I tried to connect a server, then connect a Viewer, closed the server... and everything seems running ok.

I've made a new release with more verbosity and a new Makefile. Nothing new apart from this two modifications. In order to get more verbosity the application should be compiled with _DEBUG defined. To do so, just add an argument to make:

Code: Select all

make CFG=debug

It should be more verbose.

Hope we can trap this error soon. Thanks again for your support.

[vcka]

After building new version, uvnc viewer after entering password: Unknown VNC authentication result! repeater log : UltraVNC> Viewer connection accepted from x.x.x.x.
ERROR: zero bytes read
UltraVNC> viewer_listen(): Reading ClientInit message error.

Here is original uvnc repeater log after i close uvnc server:
UltraVnc Tue Jun 1 16:02:45 2010 > routeConnections(): starting select() loop, terminate with ctrl+c
UltraVnc Tue Jun 1 16:03:00 2010 > routeConnections(): new server connecting, accepting...
UltraVnc Tue Jun 1 16:03:00 2010 > acceptConnection(): connection accepted ok from ip: 193.227.102.26
UltraVnc Tue Jun 1 16:03:00 2010 > nonBlockingRead(): start
UltraVnc Tue Jun 1 16:03:01 2010 > nonBlockingRead(): returning normally
UltraVnc Tue Jun 1 16:03:01 2010 > parseId(): IdCode = ID:87654321
UltraVnc Tue Jun 1 16:03:01 2010 > acceptConnection(): Server sent code 87654321
UltraVnc Tue Jun 1 16:03:01 2010 > findDuplicateIdIndex(): similar ID not found
UltraVnc Tue Jun 1 16:03:01 2010 > addServerList(): Server added to list: code = 87654321, index = 0
UltraVnc Tue Jun 1 16:03:01 2010 > findViewerList(): Warning, viewer not found (code = 87654321)
UltraVnc Tue Jun 1 16:03:01 2010 > acceptConnection(): respective viewer has not connected yet
UltraVnc Tue Jun 1 16:03:01 2010 > nonBlockingRead(): start
UltraVnc Tue Jun 1 16:03:06 2010 > nonBlockingRead(): returning 12 bytes
UltraVnc Tue Jun 1 16:03:06 2010 > readPeerHandShake(): len = 12
UltraVnc Tue Jun 1 16:03:30 2010 > isPeerDisconnected: recv() returned 0 (peer has disconnected orderly)
UltraVnc Tue Jun 1 16:03:30 2010 > connectionRemover(): Removing server 87654321 at index 0 (peer has disconnected)
UltraVnc Tue Jun 1 16:03:30 2010 > removeServerList(): Server Removed from list: code = 87654321, index = 0

Here is log from Your older bild when i close uvnc server (wich is much informative ;]):

UltraVNC> Add_server_list(): Server added with ID 5774425abc1fcbe5d749aed648ad83d2.
As you can see nothing happened. Then my server is disconnected and i start viewer session with same password, log:

UltraVNC> Add_viewer_list(): Viewer added with ID 5774425abc1fcbe5d749aed648ad83d2.
UltraVNC> do_reapeater(): Starting repeater for ID 5774425abc1fcbe5d749aed648ad83d2.
UltraVNC> do_repeater(): connection closed by server.
UltraVNC> Remove_server_list(): Server Removed from list 5774425abc1fcbe5d749aed648ad83d2
UltraVNC> Remove_viewer_list(): Viewer Removed from list 5774425abc1fcbe5d749aed648ad83d2

[shadowfax]

vcka: Is the new repeater version working on Linux?

Ok, let's see the log messages. I have to make them easier to read in my version...

After building new version, uvnc viewer after entering password: Unknown VNC authentication result! repeater log : UltraVNC> Viewer connection accepted from x.x.x.x.
ERROR: zero bytes read
UltraVNC> viewer_listen(): Reading ClientInit message error.

"Zero bytes read" usually means there is a closed socket. In order to take the password as a repeater ID the repeater has to act as a real VNC server until the ClientInit is sent. Therefore, the last step while connecting a viewer is retrieving the ClientInit message. At this stage the Viewer is talking directlly with the repeater and that certainly worries me. However I've been unable to reproduce this error on the Windows version and got the network adapter problems on the virtual machine. Does this happen each time you connect the viewer? Even with no server connected?

Here is original uvnc repeater log after i close uvnc server:
UltraVnc Tue Jun 1 16:02:45 2010 > routeConnections(): starting select() loop, terminate with ctrl+c
UltraVnc Tue Jun 1 16:03:00 2010 > routeConnections(): new server connecting, accepting...
UltraVnc Tue Jun 1 16:03:00 2010 > acceptConnection(): connection accepted ok from ip: 193.227.102.26
UltraVnc Tue Jun 1 16:03:00 2010 > nonBlockingRead(): start
UltraVnc Tue Jun 1 16:03:01 2010 > nonBlockingRead(): returning normally
UltraVnc Tue Jun 1 16:03:01 2010 > parseId(): IdCode = ID:87654321
UltraVnc Tue Jun 1 16:03:01 2010 > acceptConnection(): Server sent code 87654321
UltraVnc Tue Jun 1 16:03:01 2010 > findDuplicateIdIndex(): similar ID not found
UltraVnc Tue Jun 1 16:03:01 2010 > addServerList(): Server added to list: code = 87654321, index = 0
UltraVnc Tue Jun 1 16:03:01 2010 > findViewerList(): Warning, viewer not found (code = 87654321)
UltraVnc Tue Jun 1 16:03:01 2010 > acceptConnection(): respective viewer has not connected yet
UltraVnc Tue Jun 1 16:03:01 2010 > nonBlockingRead(): start
UltraVnc Tue Jun 1 16:03:06 2010 > nonBlockingRead(): returning 12 bytes
UltraVnc Tue Jun 1 16:03:06 2010 > readPeerHandShake(): len = 12
UltraVnc Tue Jun 1 16:03:30 2010 > isPeerDisconnected: recv() returned 0 (peer has disconnected orderly)
UltraVnc Tue Jun 1 16:03:30 2010 > connectionRemover(): Removing server 87654321 at index 0 (peer has disconnected)
UltraVnc Tue Jun 1 16:03:30 2010 > removeServerList(): Server Removed from list: code = 87654321, index = 0

Here is log from Your older bild when i close uvnc server (wich is much informative ;]):

UltraVNC> Add_server_list(): Server added with ID 5774425abc1fcbe5d749aed648ad83d2.
As you can see nothing happened. Then my server is disconnected and i start viewer session with same password, log:

UltraVNC> Add_viewer_list(): Viewer added with ID 5774425abc1fcbe5d749aed648ad83d2.
UltraVNC> do_reapeater(): Starting repeater for ID 5774425abc1fcbe5d749aed648ad83d2.
UltraVNC> do_repeater(): connection closed by server.
UltraVNC> Remove_server_list(): Server Removed from list 5774425abc1fcbe5d749aed648ad83d2
UltraVNC> Remove_viewer_list(): Viewer Removed from list 5774425abc1fcbe5d749aed648ad83d2

I guess you are referring to the list removals... Why does mine remove viewer and server while the other one just removes the server?

I think the older Linux version of the VNC repeater keeps the handshaking process in memory in order for the viewer to stay connected. This could be done in my version (since most of the handshake is produced by the repeater itself). The eaiest way would be for the repeater to keep in memory the ServerInit message and check it matches with the ServerInit stored in memory. I wanted to implent this kind of thing. One of the ideas I had was caching the images sent by the server on the repeater. This allows for the next features:

• If the server disconnects the images could be transformed to greyscale and the viewer would see the screen in greyscale until the server reconnects. Still have no clue on how to work with images, but I guess it would be learning how jpeg lib works.
• Caching images would make it possible for a http server to point towards that directory, making it possible to show the desktop through an HTTP browser. It would be a start towards opening an AJAX viewer for the repeater.

However, this are just some thoughts as first thing is first... and that is getting the repeater to do it's work correctly. That's why I'm really concerned about that error while reading the ClientInit message. Hope I can get the virtual machine fixed to track this error, but any description on how this error was produced would be great.

[vcka]

1.Starting repeater
2.Connecting vncserver with id 123
3.Connecting viewer with same password.
repeater console log:
UltraVNC> UltraVNC> Listening for incoming server connections on port 5500.
Listening for incoming viewer connections on port 5900.
UltraVNC> Nagle Algoritmh has been disabled.
UltraVNC> Server connection accepted from x.x.x.x.
UltraVNC> Nagle Algoritmh has been disabled.
UltraVNC> Viewer connection accepted from x.x.y.y.
ERROR: zero bytes read
UltraVNC> viewer_listen(): Reading ClientInit message error.
ERROR: zero bytes read
UltraVNC> server_listen(): Reading authentication type error.
I'm using debian 64bit

[shadowfax]

New version uploaded.

New Features

• Added the methods to free slots with broken connections awaiting for the other side to connect.
• Lowered CPU usage.
• More verbosity for the DEBUG version.
• Some messages are clearer.

Binary files uploaded to: http://code.google.com/p/vncrepeater

[vcka]

After several time closing viewer i've got this log:
UltraVNC> Viewer connection accepted from 127.0.0.1.
ERROR: Trying to allocate an empty slot.
^C
Exiting VNC Repeater...
FATAL: Failed to free repeater slots.

[shadowfax]

You can ignore the fatal error while exiting the repeater since the slots are being freed but I missed to decrement the counter at one spot of the code. I'll be fixing it in the next release.

I'll look what could be throwing the "ERROR: Trying to allocate an empty slot".

In the next release I'll be adding mutex for the slots. This should solve some problems when more than one thread is accessing the repeater slots. I will also try to port a function working on Windows to Linux so they are 100% identical.

Now it's time to eat here at Spain, hope to get all the new version in a couple of hours.

Thanks again for reporting.

[shadowfax]

The latest version has been uploaded to subversion. However, once again, google code is blocking access to the uploads therefore the only upload I've managed so far is the LINUX binary (release version). I hope to get the rest of the binary files uploaded sortly.

Changes

• Thread functions have been defined on a separate file and some new methods have been declared.
• Mutex has been implemented to avoid multiple threads accessing the repeater slots simultaneously.
• Small fix to the repeater slot counter.
• Even more verbosity on the debug version.

[bigdessert]

well I finally got an Iphone today and this was the first thing I tried. I am using the latest linux release and tried using mocha vnc lite and ezdesktop and cannot get either to work with the linux repeater. Basically the server connects fine, it shows the viewer connect message but nothing happens on the iphone.....it just keeps trying to connect. Any Ideas?

[shadowfax]

Hi bigdessert,

Sorry for the delay. Have you solved the problem?

If both ends are connected but the viewer keeps trying to connect it is most likelly that the IDs from the server and the viewer are not matching. The server side is the same as a normal repeater connection where you specify the ID. The viewer side defines the ID through the password so:

• Check the password is set in the viewer.
• Check the password matches the Repeater ID.

Note: Remember that the password is the numeric part of the repeater id. That is, if you are connecting to the server "ID:1234", the password is only "1234".

In Mocha VNC Lite -the one I use for testing since it is free- I alway disable the "Save Password(s)" as the password shall be retyped to match the ID. This brings the connection preferences window when connecting.

Please, if it continues to fail, please tell me what ID you're using at the server side, and what you are typing as a password in order to recreate the error.

[bigdessert]

well just tried it again with iteleport or jadduu vnc. when I connect I can see both the view and the server, but my iphone viewer just sits at Authenticating. This is using the latest linux release. here is what the console looks like

Code: Select all

UltraVNC> Listening for incoming viewer connections on port 5900.
UltraVNC> Listening for incoming server connections on port 5500.
UltraVNC> Nagle Alorithm has been disabled.
UltraVNC> Server connection accepted from xxx.xxx.xxx.xxx.
UltraVNC> Server waiting for viewer to connect...
UltraVNC> Nagle Alorithm has been disabled.
UltraVNC> Viewer connection accepted from xxx.xxx.xxx.xxx.

[shadowfax]

There was a problem with the MutEx handling under GNU/Linux. This bug bloked the application.

New code uploaded to the repository.

Makefile has been changed under GNU/Linux. To make the release version type "make release", to make the debug version type "make debug".

UPDATE: Linux and Windows binaries uploaded.

[vcka]

Testing. Every thing looks fine

[bigdessert]

anyone else having trouble with the linux reapeater version crashing??

[shadowfax]

Outputting the raw binary "challenged" ID could cause troubles under Linux. I've done a small modification in order to store the original repeater ID sent by the server in order to display the clear text repeater ID for monitoring purposeses.

Hope you enjoy.