Wireshark · Wireshark-users: Re: [Wireshark-users] Question on interpreting TCP Expert Info

["Small, James" <JSmall@xxxxxxxxxxxxxx>]

Boy, isn't that the truth.  Even after reading Steven's first book, I
don't think I truly appreciated just how complex TCP really is until
looking at lots of WAN traces.

I've definitely picked up a lot from listening to the group.

This is one I saved though and I still don't completely understand:

Question:
Has there been any movement to re-introduce the SEQ/ACK breakout into
Wireshark?  We found this to be one of the most valuable capabilities in
Ethereal and used it for finding network times for remote subnets.
Below is a typical portion of a tethereal script that was used for
getting an RTT for only the TCP handshake.  This proved very valuable in
quickly separating out an application-related delay versus a network
delay and could keep a running file of network response times,
especially valuable when limited to a specific remote subnet.  This
example, of course, relied on activation of the TCP relative sequence
number feature:
-z io,stat,60,AVG(tcp.analysis.ack_rtt)"((tcp.flags.syn==1 or
(tcp.seq==1
and tcp.ack==1 and tcp.len==0)) and tcp.analysis.ack_rtt"

Answer:
Can you check the wiki for TCP to make sure this feature is documented
properly and that there are useful examples on how one can use this
feature and why one might want to use it?  Since you find this feature
useful (as did the others that have noticed it went missing in the big
analysis rewrite and cleanup) it would be very useful if someone that
does use the feature could look at the wiki and make sure it is properly
documented - both what it does and why it is useful so others can also
benefit from it.

To make it more accurate would be to enhance it to ONLY collect the RTT
for PSH segments (since tcps are not doing delayed-ack on such segments)
and only if there were no retransmissions between the datasegment and
the ack.
/End


At any rate I ordered the new Wireshark/Ethereal book and am definitely
looking forward to the part about MATE.

--Jim


> -----Original Message-----
> From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-
> bounces@xxxxxxxxxxxxx] On Behalf Of Hansang Bae
> Sent: Thursday, January 04, 2007 9:10 PM
> To: Community support list for Wireshark
> Subject: Re: [Wireshark-users] Question on interpreting TCP Expert
Info
> 
> At 04:28 PM 12/29/2006, Small, James wrote:
> >Hello, I am using Wireshark to look at mail traffic
> >(SMTP/POP3).  When I look at the trace I see lots of the following:
> >Previous Segment Lost Retransmission (suspected) Duplicate ACKs I'm
> >suspecting that this is exacerbated by not having enough Internet
> >bandwidth. My question is, how do I interpret this?  Does this show
> >that I don't have enough bandwidth?  Does it mean there needs to be
> >tuning? I realize this is not an easy question and would be very
> >happy even with a go ready book ABC answer - just as long as once I
> >read book ABC I would know how to interpret the data. Any and all
> >advice greatly appreciated.
> 
> 
> 
> First thing I would check is to make sure you don't have a duplex
> mismatch.  Chances are, you are using some type of a cable modem
> router.  These devices for the most part auto-negotiate.  You don't
> (typically) have much of a choice in the matter.
> 
> So it's imperative that your PC's NIC is in auto-negotiate mode.
> 
> There really aren't to many books on using protocol analyzers.  The
> reason is that to TRULY understand protocol analysis, you need in
> depth understanding of the protocols itself.  Then, you need a lot of
> practice reading trace files as this is more art then science.
> 
> hsb
> 
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users