Wireshark · Wireshark-dev: Re: [Wireshark-dev] Possible Bug in identifying the segment an ACK isassociated with in TCP SEQ/ACK

["Maynard, Chris" <Christopher.Maynard@xxxxxxxxx>]

I think frame 213 is being categorized as an ACK to the segment in frame
212 because the TCP ACK # of 2153 is greater than or equal to Frame
212's TCP SEQ # plus segment length, which is SEQ # 2153 and segment
length zero.

To compare, if you look at frame 211, it is categorized as an ACK to the
segment in frame 209 because its ACK #2153 >= frame 211's TCP SEQ# of
2140 plus frame 211's segment length of 13, which makes sense.

My guess is that the problem only occurs when you have segment lengths
of zero.  Not sure how the core Wireshark developers feel about this,
but I guess I would suggest filing a bugzilla bug report for it.
 
By the way, if any core Wireshark developers are reading this, I do have
a separate TCP SEQ/ACK related bug still open:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1847.  Perhaps
someone could take a look at it?
 
Thanks,
Chris

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Visser, Martin
Sent: Thursday, October 25, 2007 1:42 AM
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Possible Bug in identifying the segment an ACK
isassociated with in TCP SEQ/ACK analysis

Please correct me if I'm wrong, but I think there is an error in the way
wireshark identifies a segment that is accociated with an ACK in the TCP
SEQ/ACK analysis. Consequently this affects RTT calculation. In summary
I think that Wireshark is incorrectly calculating this on the last
segment matching the ACK rather than the first.

Looking at the following print out from wireshark 0.99.5 :-

Number  Time     Len   Source                Destination
Protocol Info
    209 4.025    67    1.153.236.167       10.17.190.67          TCP
2747 > 2598 [PSH, ACK] Seq=2140 Ack=11066 Win=64067 Len=13

    210 4.098    84    10.17.190.67          1.153.236.167       TCP
2598 > 2747 [PSH, ACK] Seq=11066 Ack=2140 Win=63066 Len=30

    211 4.177    1514  10.17.190.67          1.153.236.167       TCP
2598 > 2747 [ACK] Seq=11096 Ack=2153 Win=63053 Len=1460
Frame 211 (1514 bytes on wire, 1514 bytes captured)
Internet Protocol, Src: 10.17.190.67 (10.17.190.67), Dst: 1.153.236.167
(1.153.236.167)
Transmission Control Protocol, Src Port: 2598 (2598), Dst Port: 2747
(2747), Seq: 11096, Ack: 2153, Len: 1460
    Source port: 2598 (2598)
    Destination port: 2747 (2747)
    Sequence number: 11096    (relative sequence number)
    [Next sequence number: 12556    (relative sequence number)]
    Acknowledgement number: 2153    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
    Window size: 63053
    Checksum: 0x9142 [validation disabled]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 209]
        [The RTT to ACK the segment was: 0.152378000 seconds]

    212 4.177    54    1.153.236.167       10.17.190.67          TCP
2747 > 2598 [ACK] Seq=2153 Ack=12556 Win=64512 Len=0

    213 4.180    1244  10.17.190.67          1.153.236.167       TCP
2598 > 2747 [PSH, ACK] Seq=12556 Ack=2153 Win=63053 Len=1190

Frame 213 (1244 bytes on wire, 1244 bytes captured)
Internet Protocol, Src: 10.17.190.67 (10.17.190.67), Dst: 1.153.236.167
(1.153.236.167)
Transmission Control Protocol, Src Port: 2598 (2598), Dst Port: 2747
(2747), Seq: 12556, Ack: 2153, Len: 1190
    Source port: 2598 (2598)
    Destination port: 2747 (2747)
    Sequence number: 12556    (relative sequence number)
    [Next sequence number: 13746    (relative sequence number)]
    Acknowledgement number: 2153    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 63053
    Checksum: 0xef6f [validation disabled]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 212]
        [The RTT to ACK the segment was: 0.002386000 seconds]
Data (1190 bytes)


Frame 209 contains the first segment containing bytes from the segment
with relative sequence number 2153 from 1.153.236.167. Now this is ACKed
by 10.17.190.67 in frame 211 with a correct RTT of 0.152378000 seconds.

(The avg network RTT is around 100ms).

Now in frame 212, 1.153.236.167 has no more segments to send yet, so is
happy to send a pure ACK to 10.17.190.67 with a seq still of 2153. 

1.153.236.167 is sending more data in frame 213, and of course is still
going to send an ACK of 2153. But this ACK is not necessarily an ACK of
Frame 212, which is what SEQ/ACK analysis says it is!!! I know this
because of the physical RTT and that there is no way frame 212 could
have reached the other end (and the calculated RTT in 213 is 0.002386000
secs)

So I guess what I am trying to say is that wireshark is overzealously
associating ACKs with SEQs. As it has already seen an ACK to SEQ 2153 I
don't believe it should record a second one at this point. I need
wireshark in the SEQ/ACK analysis to only record times it definitely can
determine from the trace. While in some circumstances frame 213 could be
ACKing frame 212, I think that heuristically it can't assume that,
particularly as this SEQ has already been ACKed earlier by frame 211. I
really don't need wireshark to report artificially low RTTs. 

I am happy to be tarred and feathered if I have this one wrong.

Regards, Martin

Martin Visser

Technology Consultant 
Technology Solutions Group - HP Services

410 Concord Road
Rhodes NSW  2138
Australia 

Mobile: +61-411-254-513
Fax: +61-2-9022-1800     
E-mail: martin.visserAThp.com

This email (including any attachments) is intended only for the use of
the individual or entity named above and may contain information that is
confidential, proprietary or privileged. If you are not the intended
recipient, please notify HP immediately by return email and then delete
the email, destroy any printed copy and do not disclose or use the
information in it.

 
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev

-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.