etheral

No. Time        Source                Destination           Protocol Info
> 834 *REF*       89.194.102.223        89.89.200.210         TCP      1137 > 1152 [SYN] Seq=0 Len=0 MSS=1460

This is the initial TCP-SYN which should set up the connection. The seq=0
is due to your wireshark setting to use reletive sequence numbers.

> 835 0.000640    89.194.102.223        89.89.200.210         TCP      [TCP Previous segment lost] 1137 > 1152 [SYN] Seq=21767 Len=0 MSS=1460

Somehow the client tries a second time to establish a connection using the
same src-port, but now with a different sequence-number. Since wireshark
kept track of the sequence-numbers for this conversation, it thinks there
was data missing in between the two packets, as the sequence number is now
21767 higher than that in the frame 834. Hence the "[TCP Prev ious
segment lost]" message.

> 836 0.001345    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460

This is the SYN/ACK to the SYN in frame 834 (because the ack=1, the ack of
a SYN/ACK is always 1 higher than the seq of the SYN).

> 837 0.001360    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [RST] Seq=1 Len=0

Since your client sent another SYN with a higher sequence number (frame 835)
it thinks this SYN/ACK is not valid (it's valid to frame 834, not to 835),
the client drops the connection.

> 838 0.001371    89.89.200.210         89.194.102.223        TCP      [TCP Dup ACK 836#1] 1152 > 1137 [ACK] Seq=1 Ack=1 Win=5840 Len=0

This ACK I can't place

> 839 0.001379    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [RST] Seq=1 Len=0

This is a RST on the ack in frame 838, cause it is out of sequence

> 840 2.993571    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [SYN] Seq=21767 Len=0 MSS=1460

This is a retransmission of the SYN in frame 835

> 841 2.994880    89.89.200.210         89.194.102.223        TCP      [TCP Previous segment lost] 1152 > 1137 [SYN, ACK] Seq=2993603 Ack=21768 Win=5840 Len=0 MSS=1460
> 842 2.994909    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [ACK] Seq=21768 Ack=2993604 Win=17520 Len=0
> 843 2.995387    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [PSH, ACK] Seq=21768 Ack=2993604 Win=17520 Len=9
> 844 2.996103    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [ACK] Seq=2993604 Ack=21777 Win=5840 Len=0
> 845 3.084802    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [PSH, ACK] Seq=2993604 Ack=21777 Win=5840 Len=22
> 846 3.084829    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [FIN, ACK] Seq=2993626 Ack=21777 Win=5840 Len=0
> 847 3.084853    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [ACK] Seq=21777 Ack=2993627 Win=17498 Len=0
> 848 3.085844    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [FIN, ACK] Seq=21777 Ack=2993627 Win=17498 Len=0
> 849 3.086408    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [ACK] Seq=2993627 Ack=21778 Win=5840 Len=0

And this is the normal flow of packets...

The big question is where does the second SYN packet come from...