|
Thanks for the excellent reply.
Do you have a date for the release of the next version of Wireshark?
> Date: Fri, 7 Dec 2007 09:59:39 +0100
> From: sake@xxxxxxxxxx
> To: wireshark-users@xxxxxxxxxxxxx
> Subject: Re: [Wireshark-users] A few questions
>
> 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
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
Søk fra enhver webside med kraftig beskyttelse. Få Windows Live Toolbar GRATIS i dag! Hold kontakten med venner og familie med Messenger
|
