[Sake Blok <sake@xxxxxxxxxx>]

Hi Lars,

I will answer your questions in reverse order as they are related to each
other and the answer on 3 helps to understand 2 and 1 :-)

> #3. Viewing a tcp packet I noticed that it was stamped iwth 'TCP 
> Retransmission'. Fair enough, just a lost packet being
> retrasmitted (the packet was timestamped 16:17:00 btw). Then I looked 
> at the SEQ\ACK analysis 'This fram is a (suspected)
> retransmission. The RTO for this segment was 12460.784541000 seconds). 
> RTO based on delta from frame 31 688. Frame 31688 was sent
> 12:49:19 - thats almost 4 hours difference in time. What does this 
> mean? It can be retransmitting a packet 4 hours later? Thought this
> was strange.

As you mentioned in your mail, the same tcp-ports are used again
after a while. The version of Wireshark that you are using does not
check for a SYN. So it sees the new session as a continuation
of an earlier session. Since the seq-nr on the syn of the new session
is lower than that of the last seen packet for "this tcp session",
it marks is as a retransmission.

In the upcoming Wireshark release, Wireshark checks if a packet is a 
SYN and if it is, it will create a new conversation in it's state
table. This solves these messages.


> #2. The communication between server and client uses a fixed pattern 
> of send \recv with only small change in parts of the content. One
> tcp transmission (from SYN to FIN) usually consists of roughly 110 
> packets and the sequence number on client reaches seq=141 and on 
> server seq=137. For some unknown reason (for me atleast) the tcp 
> packets start using extremely high sequence numbers (they
> dont slow increase in size, they just make a huge jump). So suddenly 
> Im getting sequence numbers like 3367739430. Can anyone
> explain why this is happening? Should I be worried about these high 
> number or can I just ignore them?

TCP sequence numbers are actually (almost) never these low values. The
first seq-nr is chosen randomly and it's a 32-bit counter. So the actual
sequence numbers on the wire are mostly high numbers. Wireshark has 
the option to show relative sequence numbers. You can select that
in the TCP protocol preferences. By default it is selected I believe.
But when issue #3 occurs, there is a new randomly chosen seq-nr
to start the new conversation with. Since the current version of
Wireshark does not see this as a new session, it will still calculate
the relative sequence number against the old session. Hence the high
numbers in this case.

> #1. When selecting a tcp packet and clicking on 'follow tcp stream' 
> what constitute a tcp stream? It appears to me that if source and
> destination port match = tcp stream. This comes out a bit odd on 
> my system since the server port changes port between each transmission 
> hence it at some point in time the server will re-use a 
> source\destination port. So When I do 'follow tcp stream' it appears 
> Im getting several stream with quite different timestamps on them.
> Have I understood the functionality of 'follow tcp stream', am I 
> using it correctly?

Yes, the current implementation of "Follow TCP stream" will filter on
both ip-addresses and tcp-ports. When a new session uses the same
addresses and ports, it will match the filter and also these packets will
be shown in packet-list. 

I hope this explains to you what you are seeing :-)

Cheers,
    Sake