Repeater hangs

Ghost · Post by **Ghost** » 2005-11-09 08:39

Hi everybody,
I'm using SC or "Add new client with ID code" with WinVNCsc 20.3, WinVNC 1.0.1 and Repeater 1.0.4.
Very often after a period of correct functionality the repeater stops accepting server connections, i.e. in the logs I see only
accept() connection
Viewer added to list 9999
but not
Server added to list 9999
without any errors. Restarting the repeater solves this problem.
What can this be?

BTW: what about source code of the repeater?? if this was available I could add some debug info myself...

Thanks
Davide

Post by **Rudi De Vos** » 2005-11-09 10:08

Sources are on soureforge
http://sourceforge.net/project/showfile ... p_id=63887

Please let us know if you find the bug...
The problem is that it does not happen a lot of times, making it hard to debug.
You need to see what happen before block ( possible you need to add a lot of comments and write it to a file)

_Ghost_ · Post by **_Ghost_** » 2005-11-30 11:36

After some days of testing with a modified repeater with added debug infos, I can't still find the problem... after some connections it seems that the repeater does not accept server connections anymore on port 5500; the port is open, but for example trying to connect to the repeater with netcat with "nc server 5500" it returns immediately instead of waiting for input (like the normal situation).
Using procexp I saw that the repeater is listening to 5500 and the listening thread is open; I added a debug message "server accept" in the else part just after the
connection = accept( sock, &client, &socklen);
but I don't get any message, accept nor error!

Any help is appreciated...
...but I don't understand why I am the only one having this problem!

Thanks
Davide

RepeaterNotResponding · Post by **RepeaterNotResponding** » 2005-12-02 05:52

I have previously reported this problem but no-one responded to my message. I resorted to creating a schedule that stops and starts the repeater service periodically. Sorry I can't help you but rest assured you are not the only one that is having the problem. Thanks for putting in the effort in trying to identify the problem. I'm using repeater version 1.1.0.4

_Ghost_ · Post by **_Ghost_** » 2005-12-02 14:20

Glad to see I'm not the only one...
This is a very BIG problem with the repeater use, and appears so frequently that solving it is a MUST.
Instead on focusing on NAT2NAT, SCiii etc etc why not focusing on making the basic things more reliable?

Any help on debugging/solving this issue is kindly appreciated (ehi Rudi!!!)

Thanks everybody
Davide

-bom- · Post by **-bom-** » 2005-12-04 10:08

Same problem here
But after the last windows update the repeater has bin more stable,
I’m running on a w2k full updated now, don’t if there is a link or this is pure luck.

Like to here if any has any the final solution

_Ghost_ · Post by **_Ghost_** » 2005-12-20 10:15

Hi all,
I have solved the problem of the repeater (at least for now and at least for me...). I found that the repeater was not accepting connections anymore when a client (be winvnc or vncviewer) remain stuck just after establishing a connection and the repeater remains blocked while recv'ing the ID:xxxx; since the listen was used with a backlog of 1, the connection in immediately refused for all next releases.
I solved specifying a timeout with SO_RCVTIMEO and SO_SNDTIMEO before the ReadExact.
If someone is interested I can send the code and/or the exe by email (I don't a permanent IP address).
I also added some other useful info (active connections monitoring, better logging system, ecc...)

Bye
Davide

RepeaterNotResponding · Post by **RepeaterNotResponding** » 2005-12-20 21:43

I'm glad you found a way to make the repeater more reliable. Could you email the exe to repeater@email.com . I'll keep you posted as to how I make out with your version.
Thanks,

Joe

Post by **Rudi De Vos** » 2005-12-21 00:05

Good news, several people where looking for that part in the code.

TalynOne · Post by **TalynOne** » 2005-12-22 06:59

Hi Davide,

Could you please send me the updated .exe? It would be greatly appreciated.

vnc@bitspy.com

Thanks

simham_uk · Post by **simham_uk** » 2005-12-22 14:19

Does the repeater with the fix have the SSL support built in already or is it based on an older version?

Thanks

--
Simon H

_Ghost_ · Post by **_Ghost_** » 2005-12-22 14:35

No it is a slightly modified version of the 1.1.0.4 version, for use with "Add new client" with ID code and/or SingleClick V1.

simham_uk · Post by **simham_uk** » 2005-12-22 15:08

_Ghost_ wrote:No it is a slightly modified version of the 1.1.0.4 version, for use with "Add new client" with ID code and/or SingleClick V1.

Can you send it to me at simon.hamiltonREMOVECAPS@ntlworld.com anyway, so i can have a look. I've only been playing mostly with the new betas with SSL support but am keen to see the new features you've added.

Thanks

--
Simon H

simham_uk · Post by **simham_uk** » 2005-12-22 16:17

_Ghost_ wrote:No it is a slightly modified version of the 1.1.0.4 version, for use with "Add new client" with ID code and/or SingleClick V1.

What do you mean by "Add new Client". Is there some way of managing a queue of clients? If not, that would certainly be cool!

--
Simon H

redman · Post by **redman** » 2005-12-22 23:13

I have the same problem... would appreciate a copy... I could even host it on a website for others to download. send to pwsmithATgmail . c o m .

Thanks!

redge · Post by **redge** » 2005-12-22 23:58

_Ghost_ wrote:if someone is interested I can send the code and/or the exe by email

Could you update CVS file instead of send as private message to everybody ?
so developer(s) can update new repeater from 1.0.4 -->1.0.5 ?

that would be more open source and available exe for non developers !
thank you a lot for your time and finding bug and added fix

(I don't see it because I don't have the repeater.exe 1.0.4 with your fix aka 1.0.5)

Would be "easy" to be ported to repeater_ssl 1.0.5 ??

_Ghost_ · Post by **_Ghost_** » 2005-12-23 14:32

Yes obviously it would be a good thing...
I'm not am UltraVNC developer but if some of them is interested I can of course send them my patch so it can updated in the CVS, even if I think it would be better to let other some people test it before it is commited to CVS.

I have never used or seen the code of repeater_ssl so I do know about it.

Bye
Davide

Post by **Rudi De Vos** » 2005-12-23 15:04

I solved specifying a timeout with SO_RCVTIMEO and SO_SNDTIMEO

I will check the code again, a waiting readexact should not be able to
block.
Each viewer/server connection have his own thread and run independed, but possible we do a ReadExact
before we fork them in the thread, causing next connections being refused.

Thanks, you are the FIRST that actual report back some fixes.
We had a lot of mails in the past, for requesting to release the source code...we did.
But if feedback stay this low, we possible will NOT release the source code of future versions.
I just wondering what the other 2000 people are doing with it

Post by **Rudi De Vos** » 2005-12-23 15:12

Indeed,

after

Code: Select all

connection = accept( sock, &client, &socklen);

we shoud start a seperate thread and not after read/write.

A single connection can lock the whole repeater to accept new connections.

Thanks,

I never would found this concept error.

Post by **Rudi De Vos** » 2005-12-23 16:10

Update (test)

http://sc.uvnc.com/V2
distributer_105.exe

Changes:
After accept, a new thread is started. (server and viewer part)

loop
{
accept
viewer thread
}

The only thing that can happen is that the thread hang, but the repeater does not block the next accept.

I current didn't touched the SO_RCVTIMEO and SO_SNDTIMEO parameters. Changing the parameters will also have an impact on the time the viewer can wait for a server connection. Some people connect there viewer for hours and let them just waiting until the server connect.

I can hard reproduce the hang problem, so some feedback will be appriciated. (possible some other bugs where added, 5 minute code change)

redge · Post by **redge** » 2005-12-23 23:19

_Ghost_ wrote:I have never used or seen the code of repeater_ssl so I do know about it.

source code of repeater and repeater_ssl:
http://sourceforge.net/project/showfile ... _id=362112

_Ghost_ · Post by **_Ghost_** » 2005-12-24 14:11

If you change the SO_RCVTIMEO and SO_SNDTIMEO parameters just after the accept() you change the maximum time the repeater can wait to receive the ID:xxx string, that should be immediate if everything goes ok.
It does not have anything to do with the maximum time that the viewer can wait for server connections, that is regulated by the timer thread (if I rememeber 5 mins?).
Using SO_RCVTIMEO and SO_SNDTIMEO you are sure to delete "blocked" connections instead of leaving around blocked threads.
I think that the perfect solution would be spawn a thread as you said AND set the timeouts in the new thread, so you can delete it if it is blocked.

Thanks
Davide

Post by **Rudi De Vos** » 2005-12-24 16:06

Correct.....seems i don't know my own code anymore

This happen when you leave it alone for a few months.

The test
http://sc.uvnc.com/V2/
distributer_107.exe

Span thread and change default timeouts to 10 min.
The default value was unacceptable high (2000 minutes)

The timeout value is less important as the only goal is to cleanup
a hung thread. A hung thread use about 10k mem and no cpu, so
if some unecpected thing happen, we can easy increase it to an hour

[mod=2,1137322915]Corrected the URL[/mod]

redge · Post by **redge** » 2005-12-24 17:46

distributer_106.exe as SYSTEM mode crash
szAppName : distributer_106.exe szAppVer : 1.1.0.4
szModName : distributer_106.exe szModVer : 1.1.0.4 offset : 000029d1

socket() initialized
bind() succeded to port 5901
listen() succeded
socket() initialized
bind() succeded to port 5501
listen() succeded
accept() connection
Viewer added to list 7890
Server added to list 7890
log of distributor do not help anything

LAN: winvnc 1.0.1 192.168.1.32:5501(6 oct 2005)--> distributer_106
EDGE: vncviewer14BETA myhost.dyndns.org:5901--> distributer_106

error reported by vncviewer14BETA
rdr::Exception (2): rdr::SystemException: read: Unknown error (10054)
error reading protocol version: rdr::SystemException: read: Unknown error (10054)

Post by **Rudi De Vos** » 2005-12-24 20:19

Yep,

release crash...

It seems i need to add some events to be sure data is copied before
overwritten.

5 minute change

Post by **Rudi De Vos** » 2005-12-24 20:40

http://sc.uvnc.com/V2
distributer_107.exe

This one should be better...events added to wait until copy done (µs)

redge · Post by **redge** » 2005-12-24 21:11

distributer_107, back to normal work, cool

Post by **Rudi De Vos** » 2005-12-25 02:00

Now lets hope it also solve the blocking issue's

redge · Post by **redge** » 2005-12-25 14:33

to do for next of your cool free time of coding

add this fix to your public repeater_ssl uvnc.com

Post by **Rudi De Vos** » 2005-12-25 15:34

+first the normal version need to be OK....
Just wait the reports fort a few days (weeks)

+Add the same stuff to ssl
+Update uvnc.com

UltraVNC

Repeater hangs

Repeater hangs

Repeater hangs

My repeater stops responding too.

Repeater hangs

R_N_R

Repeater hangs - SOLVED

I would like your modified repeater.exe please.

Would appreciate a copy here..

CVS update