https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3155
--- Comment #1 from John Crosland <YDGMEUUBOTYB@xxxxxxxxxxxxx> 2008-12-22 10:45:37 PDT ---
I believe the issue was stated incorrectly. The statements did not match the
trace that I included. The difference is that wireshark reports packet 4 to be
an ack of packet 3 with a long rtt_ack time. Packet 3 though itself was only
an ack and did not include any user data / TCP payload. Ethereal 0.9.16 and
probably later versions of ethereal appear to more correctly not generate a
tcp.analysis.rtt_ack in its analysis of packet 4.
pkt 1 - TCP port 11012 seq/ack=1/1 - sends 4 bytes
pkt 2 - TCP port 26537 seq/ack=1/5 acks the 4 bytes / sends 4 bytes - rtt_ack
calc for data in pkt 1 is correct.
pkt 3 - TCP port 11012 seq/ack=5/5 - acks the 4 bytes and sends none - rtt_ack
calc for data sent in packet 2 is correct.
pkt 4 - TCP port 26537 seq/ack 5/5 - sends 4 bytes, repeats ack of 5 in pkt 2
-Wireshark shows packet 4 as rtt_ack of packet 3 which contained no TCP data.
Packet 4 is simply repeating the ack value that was sent in packet 2. The ack
value in packet 4 is not really acking data in packet 3 or advancing "bytes
acked" beyound the value it sent in packet 2. Ethereal does not generate an
rtt_ack in its analysis of packet 4.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.