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: [EMAIL PROTECTED]
> To: wireshark-users@wireshark.org
> 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@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-users

_________________________________________________________________
Søk fra enhver webside med kraftig beskyttelse. Få Windows Live Toolbar GRATIS 
i dag!
http://www.toolbar.live.com
_______________________________________________
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Reply via email to