Ad
News

SD cards in tight supply due to Toshiba production problems

Published on December 27, 2004

The supply of Secure Digital (SD) flash-memory cards is currently falling short of growing demand as Toshiba may be experiencing some production problems for its SD modules, according to sources with DRAM-module makers in Taiwan. Read more

Quantum attacks worry computer scientists

Published on November 03, 2006

In the weird world of quantum computing, the state of computer systems networked together is so fragile that a read access to a single quantum bit, or qubit, on one machine would require a network-wide reset. Read more

CES goes pink with Hello Kitty

Published on January 12, 2007

Most booths at the Consumer Electronics Show are pretty bland, but Spectra International's booth stood out with several walls of eye-searing pink Hello Kitty electronics. The cat face with its trademark missing mouth, a symbol of international cuteness, was plastered on everything from phones to USB sticks. There were even Hello Kitty toasters and hair dryers on display. Read more

Microsoft fixes critical IE problems

Published on December 14, 2005

Microsoft this week fixed a widely reported flaw in its Internet Explorer browser that had been used by attackers over the past few weeks to take over the PCs of unsuspecting users. Read more

Latest Reviews & Articles

Power Supply Roundup: Part II

Published on November 07, 2008

In Part I of our power supply roundup, we went through five mainstream PSUs rated at up to 700 W. Round two sees us tackle another seven mid-range units in an effort to determine which power supply deserves your attention. Read more

Roundup: The Best Overclocking Software

Published on November 06, 2008

Interested in overclocking but not quite sure where to start? We round up some of our favorite software utilities for tweaking processors, memory, graphics, and chipsets. Read more

Tom's Holiday Buyer's Guide 2008, Part 1

Published on November 05, 2008

Welcome to the first installment in our six-part Tom's Holiday Buyer's Guide. In Part 1, two beautiful models help showcase some of our favorite no-hassle hardware gifts for 2008. Read more

Round Up: Five Powerful, Light Ultraportables

Published on November 05, 2008

Executives, road warriors, and gadget geeks all lust after ultraportable notebooks. Five of these amazing machines battle it out in this roundup. Read more

  Tom's Hardware Forums » General Networking » Network General Discussions » Weird conenction problems using vnc.
 

Weird conenction problems using vnc.




Word :   Username :  
 
Bottom
Author
 Thread : Weird conenction problems using vnc.
 
Profile: stranger
More Information

Hello all,
first time on this forum, I hope I can be of assistance to some of you guys too.

My first post however, will be a problem of my own ;)

Situation:
- wireless GPRS modem with a working Internet connection situated in Jordan.
- connected to the GPRS modem: a WinXP PC with VNC server (UltraVNC) installed.
- WinXP PC with Cable Internet Connection situated in The Netherlands.

Goal:
- to take over the WinXP PC using a VNC connection form the The Netherlands to control te WInXP PC situated in Jordan. We always connect FROM the Netherlands TO the GPRS modem in Jordan.

The Problem:
- establishing the VNC connection using a cable connection.

The 'funny' thing is: VNC connection WORKS with a T1 fibre connection. With a CABLE connection however, the connection fails.
We tried various connection types: ADSL, CABLE (we tried various ISP's and operating systems!) but only the Fibre connection works. These test were done using the same pc (and some others pc's but this made no difference).
Speed should not be the issue here, because the GPRS modem clearly is the bottleneck.

Below are 2 dumps made using WireShark.
We deleted the Ip adresses from the dump and changed them to "Client" and "Server" for security reasons..
The first one is made with the WORKING connection. (WinXP->100MbitLan->T1 fibre connection->...)

The second dump is made using a CABLE connection.
(WinXP->100MbitLan->Cable connection->...)
As you can see, this connection is not established correctly...


[code:1:f1f3b5c4b4]
Time Source Destination Protocol Info

29.221180 Client Server TCP 4764 > 5900 [SYN] Seq=0 Len=0 MSS=1460
31.071030 Server Client TCP 5900 > 4764 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
31.071094 Client Server TCP 4764 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
31.920577 Server Client VNC Server protocol version: 003.006
31.920750 Client Server VNC Client protocol version: 003.003

Time Source Destination Protocol Info

5.434876 Client Server TCP 1469 > 5900 [SYN] Seq=0 Len=0 MSS=1460
7.729111 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
7.729172 Client Server TCP 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
10.524501 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
10.524550 Client Server TCP [TCP Dup ACK 10#1] 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
16.541817 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
16.541870 Client Server TCP [TCP Dup ACK 10#2] 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
28.576874 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
28.576922 Client Server TCP [TCP Dup ACK 10#3] 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
52.672502 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
52.672554 Client Server TCP [TCP Dup ACK 10#4] 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
82.548013 Server Client TCP 5900 > 1469 [RST] Seq=1 Len=0
[/code:1:f1f3b5c4b4]



We did so much testing at this point, and we are out of ideas. I hope you guys can have a look and maybe give us some hints on where to look for the problem..

Muchos Thanks in advance.

Related Product

Register or log in to remove.

Profile: enthusiast
More Information

Where are you doing your capture at? I'm guessing you are doing your capture close to the client machine because it seems that the server machine didn't receive the ACK to complete the TCP handshake and therefore retransmits the [SYN,ACK], this cycle just repeats itself. If this traffic is going through some firewall, you may need to adjust the TCP timeout for TCP protocols in the firewall. May not solve your problem but something to check.

Quote :

Hello all,
first time on this forum, I hope I can be of assistance to some of you guys too.

My first post however, will be a problem of my own ;)

Situation:
- wireless GPRS modem with a working Internet connection situated in Jordan.
- connected to the GPRS modem: a WinXP PC with VNC server (UltraVNC) installed.
- WinXP PC with Cable Internet Connection situated in The Netherlands.

Goal:
- to take over the WinXP PC using a VNC connection form the The Netherlands to control te WInXP PC situated in Jordan. We always connect FROM the Netherlands TO the GPRS modem in Jordan.

The Problem:
- establishing the VNC connection using a cable connection.

The 'funny' thing is: VNC connection WORKS with a T1 fibre connection. With a CABLE connection however, the connection fails.
We tried various connection types: ADSL, CABLE (we tried various ISP's and operating systems!) but only the Fibre connection works. These test were done using the same pc (and some others pc's but this made no difference).
Speed should not be the issue here, because the GPRS modem clearly is the bottleneck.

Below are 2 dumps made using WireShark.
We deleted the Ip adresses from the dump and changed them to "Client" and "Server" for security reasons..
The first one is made with the WORKING connection. (WinXP->100MbitLan->T1 fibre connection->...)

The second dump is made using a CABLE connection.
(WinXP->100MbitLan->Cable connection->...)
As you can see, this connection is not established correctly...


[code:1:c31bfc36b0]
Time Source Destination Protocol Info

29.221180 Client Server TCP 4764 > 5900 [SYN] Seq=0 Len=0 MSS=1460
31.071030 Server Client TCP 5900 > 4764 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
31.071094 Client Server TCP 4764 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
31.920577 Server Client VNC Server protocol version: 003.006
31.920750 Client Server VNC Client protocol version: 003.003

Time Source Destination Protocol Info

5.434876 Client Server TCP 1469 > 5900 [SYN] Seq=0 Len=0 MSS=1460
7.729111 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
7.729172 Client Server TCP 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
10.524501 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
10.524550 Client Server TCP [TCP Dup ACK 10#1] 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
16.541817 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
16.541870 Client Server TCP [TCP Dup ACK 10#2] 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
28.576874 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
28.576922 Client Server TCP [TCP Dup ACK 10#3] 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
52.672502 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
52.672554 Client Server TCP [TCP Dup ACK 10#4] 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0
82.548013 Server Client TCP 5900 > 1469 [RST] Seq=1 Len=0
[/code:1:c31bfc36b0]



We did so much testing at this point, and we are out of ideas. I hope you guys can have a look and maybe give us some hints on where to look for the problem..

Muchos Thanks in advance.

Profile: stranger
More Information

Thanksfor your reply!
We monitor at the client side.
We cannot monitor at the server side because of the phycical location of the server.
The traffic is not being send trough a firewall. Just trough a router, with all the ports forwarded, and thats it...

Profile: enthusiast
More Information

Well.. now you need to monitor on the server side to see if the ACK to complete the TCP handshake is reaching the server.


Quote :

Thanksfor your reply!
We monitor at the client side.
We cannot monitor at the server side because of the phycical location of the server.
The traffic is not being send trough a firewall. Just trough a router, with all the ports forwarded, and thats it...

Profile: stranger
More Information

The problem is we can't get to the server pc. It's situated in jordan which is a long way away from us. The only possibility to changen something on the server is to do it from here.
Using a T1 fibre connection it does work and I can take over the pc but with a cable connection it doesn't seem to work.
I compared the 2 times between a [SYN] from the client and a [SYN,ACK] from the server but there is no time difference between cable and fibre.

Profile: stranger
More Information

I was able to monitor the server side and saw that the [ACK]-pakket from the client to the server doesn't arrive at the server. 8O
The [SYN] -pakket that it sent first DOES arrive at the server uses the same ports. Any idee why the [ACK] gets blocked? thanx

5.434876 Client Server TCP 1469 > 5900 [SYN] Seq=0 Len=0 MSS=1460
7.729111 Server Client TCP 5900 > 1469 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460
7.729172 Client Server TCP 1469 > 5900 [ACK] Seq=1 Ack=1 Win=65535 Len=0 <-- this pakket doesn't arrive


  Tom's Hardware Forums » General Networking » Network General Discussions » Weird conenction problems using vnc.

Go to:
 

Google Ads