Connection dropped, trying to reconnect

[peking1983]

I have been having issues using UVNC on my local machine (WinXP 32bit).
It was v1.1.9.0 and I have changed to v1.1.9.3 but no changes.

Occasionally when I connect to a machine (typically Win7x64 but it also has the same latest VNC version) I get the connection dropped, trying to reconnect happening nonstop until I exit the viewer. If I were to try this on another machine, with the same VNC version as me (both XP 32bit and Win7x64) they are able to connect without issue.

What I have tried:

1. uninstall, reboot and run ccleaner, reboot and fresh install for latest version

• telnet to machine on vnc port 5900 and connects (rules out firewall issues)

• tested with javaviewer but it failed, so I removed all java versions on the machine without installing any. Now javaviewer will work to that machine with Firefox

• fresh install of v1.1.9.3 but nothing changed

Everything on the destination machine seems correct as it will accept connections from other machines, but not my machine. Are there any known conflicts that could be causing this to occur for me? I can get by with the javaviewer but it's slow and loses some functionality that I want.

I don't want to have to wipe my machine to use UltraVNC but I don't see anything that would be causing an issue on my machine as it's also installed on the other machines I had tested with.

Are there any ideas what I should try in order to correct this?

[Rudi De Vos]

This is a strange one...

1) Try to delete the viewer presets (delete saved settings button) in the viewer opening window and restart viewer.
(uninstall doesn't clear this file)

2° Tty with disabled firewall on the viewer pc

3° Check if working viewer has some version as the bad oner

[peking1983]

It is strange because I am able to connect to all XP machines and most of the Win7 machines. This only happened with one machine previously and now seems to be several that were setup with v1.1.9.3

Resetting the settings did not seem to make a difference.
Windows firewall on the viewer was already off.
All the versions I'm testing with were installed with v1.1.9.3

Is there anything I am able to log on the viewer to troubleshoot? I see the logs on the server.

[Rudi De Vos]

viewer command lines
-loglevel loglevel
Set the loglevel. This can range from 0 (minimal) to 10 (maximum logging).
-console
Open a console window for log output.
-logfile filename
Log to the file specified by filename.

Have you already tried with setting a fixed encoder instead of auto. ( viewer options).
WiFi, ethernet ? There are reports that some WiFi behave bad with vnc data.

[peking1983]

I tested with all of the different viewing options after your post but it did not change anything.
The network is ethernet over a VPN. If it was a firewall issue (which is usually the error to fix) then I shouldn't be able to telnet to port 5900 on the destination machine.

I have the log that shows an unknown error but gives an error code that you may be able to shed some light upon. I waited until it reconnected before I closed out and stopped the log.

Code: Select all

Started and Winsock (v 2) initialised
bufsize expanded to 4352
Registered connection with app
Connected to xxx.xxx.xxx.xxx port 5900
DSMPlugin not enabled
RFB server supports protocol version 3.8
Connected to RFB server, using protocol version 3.8
VNC authentication succeeded
Read a 46-byte string
Desktop name "MYPCNAME ( xxx.xxx.xxx.xxx ) - service mode "
Geometry 1920 x 1080 depth 32
Screen work area is 1280 x 964
Reset keyboard for first use
Flush dead key gives: 1 character(s): 0x0020 ( )
Clipboard changed
Ignore Clipboard while initializing!
No next window in chain; WM_DRAWCLIPBOARD will not be passed
SetClipboardViewer to 0x00530530; next is 0x00010620. Last error 0x00000002Cache: Cache buffer bitmap creation
Screen work area is 1280 x 964
Update-processing thread started
Screen work area is 1280 x 964
Screen work area is 1280 x 964
ServerState- reading 11 bytes
ServerState (2, 5)
New keepalive interval 5Read remote clipboard change
Read remote extended clipboard change
rdr::Exception (1): rdr::SystemException: read: Unknown error (10054)
Connected to xxx.xxx.xxx.xxx port 5900
DSMPlugin not enabled
RFB server supports protocol version 3.8
Connected to RFB server, using protocol version 3.8
VNC authentication succeeded
Read a 46-byte string
Desktop name "MYPCNAME ( xxx.xxx.xxx.xxx ) - service mode "
Geometry 1920 x 1080 depth 32
Screen work area is 1280 x 964
Requesting new pixel format
Cache: Cache buffer bitmap creation
Update-processing thread finishing
WndProchwnd ChangeClipboardChain hwnd 0x00530530 / m_hwndcn 0x00530530, 0x00000000 (1)
Deregistered connection from app
Exiting
VNC viewer closing down

[Rudi De Vos]

Info from realvnc website
http://kb.realvnc.com/questions/75/I%27 ... 0054%29%22

I'm receiving the error "Connection reset by peer (10054)"
"Connection reset by peer" generally suggests a network issue (not related to the application itself), this could be due to either misconfigured or faulty network hardware.

"Connection reset by peer" specifically means that, as far as the application reporting the error is concerned, the other endpoint sent a TCP reset packet. Sometimes, both endpoints report this error, in which case something in the middle has sent reset packets to both ends. It's not possible for the endpoints to get any more information than this. That unfortunately means the VNC Viewer cannot tell what has caused the error.

If you wish to troubleshoot this issue, investigating the quality of the connection between viewer and server is the best place to start. Try sending large ping packets and do a long-ish ping test and look for any packet loss. A payload of around ~1350 bytes is ideal.

From a command prompt:

ping -t -l 1350

N.B. it is a "dash lowercase-L" above, not a 1, they look the same in some fonts.

One common cause of this error is that the MTU (Maximum Transmission Unit) size of packets travelling over your network connection have been changed from the default of 1500 bytes. This could have been configured manually (usually within router settings), or could be due to running VNC over a VPN connection.

[peking1983]

I was unable to address this problem while being tied up with critical issues but it had arisen for our Network Administrator as well. All I had found from this previous post was it wasn't an MTU issue.

What it turned out to be was the router had some intrusion protection rules that was causing this to be rejected and dropping the connection. With the version of UVNC it would automatically reconnect seeming to be in an endless loop.

I am not sure why it worked for other machines but not mine, perhaps a different (older) version of VNC didn't have certain rules that match it's restrictions.

As for why it worked with the Java applet through the browser, I assume the rules did not handle that case. After we added exceptions for our network to the Intrusion rules, everything is working properly.

I just wanted to update this as resolved because it's quite possible this will happen to somebody else in the future and with intrusion protection on a router was new to me until this week.