["ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>]

On Dec 7, 2007 7:30 PM, Lars Lars <laasunde@xxxxxxxxxxx> wrote:
>
>
> Hi,
>
> Started using WireShark recently and got a couple of questions that I was
> hoping someone on here could answer.
>
> The purpose of using WireShark is to monitor communication between server \
> client application developed by our company.
>
> #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?
>

A tcp stream means all TCP packets that belong to the same socketpair,
i.e. the same two IPADDTESS:TCPPORT combinations.

If your application creates a new tcp connection/stream for each
transaction, then
each transaction will be a unique stream.


> #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?

In TCP,   the sequence numbers dont have any semantic meaning outside
of their relative delta from the initial SYN
packet for the stream.
SYN packets initiate a sequence number sequence by picking a
completely random (if the tcp stack is good) number as the initial
number.
TCP sequence numbers do not start with 0 when the connection is created.

However, Since the tcp sequnce number space is 32 bits, this means
that the average random tcp sequence number is a 10 digit decimal
number.
(0 - 4bilion)
and it is very difficult to see quickly the diference between two 10
digit numbers if the delta is only 1500 or so,   wireshark by default
resets the numbers when displaying them to a relative bias.
(Menu:Edit/Preferences/Protocols/TCP/RealtiveSequenceNumbers... )
The way wireshark does this is quite simple, it really just picks the
first packet it sees for that session and picks the sequence number
for that session as
'relative 0'.

The rationale for this is useability.   Since the sequence number
values themself have no meaning outside of their delta from the value
used in the SYN packet,
it doesnt matter much what value is displayed.
And 0 - 135    is MUCH easier for a human to read and understand than
3.155.678.442 - 3.155.678.577


What happened in your case is probably that you captured a trace in
mid-flight, so you did not get the initial SYN packet, instead you got
as the first packet a normal data segment  and this packet reset the
sequence number in wireshark to be 0 based on this packet.
Somewhat later you got a tcp retransmission of an earlier packet that
had been lost which had a sequence number less than the sequence
number of that firts packet in the trace, and this causes the
"relative number == number - sequencenumber of first seen packet" to
wrap below zero to ~4bilion again.

Try disabling "relative sequence numbers" in the tcp preferences and
look at the sequence numbers of the first packet and the sequence
number of the one with "huge number"   and youll see what i mean.
That packet is flagged as a retransmission   right?


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


that is odd.
can you send me a filtered minimum capture with just that tcp session
i can look at?

>
> Appreciate any help.
>
>
> ________________________________
> Windows Live Spaces er her! Det er enkelt å opprette et eget, personlig
> webområde. Sjekk det ut!
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
>
>