Weird conenction problems using vnc.

DigitEmp

Distinguished
Jun 14, 2007
4
0
18,510
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.
 

El0him

Distinguished
Feb 3, 2006
228
0
18,680
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.

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.
 

DigitEmp

Distinguished
Jun 14, 2007
4
0
18,510
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...
 

El0him

Distinguished
Feb 3, 2006
228
0
18,680
Well.. now you need to monitor on the server side to see if the ACK to complete the TCP handshake is reaching the server.


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...
 

DigitEmp

Distinguished
Jun 14, 2007
4
0
18,510
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.
 

DigitEmp

Distinguished
Jun 14, 2007
4
0
18,510
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