https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3155
Summary: tcp.analysis.rtt_ack includes acks other than the first
Product: Wireshark
Version: 1.0.5
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: Medium
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: YDGMEUUBOTYB@xxxxxxxxxxxxx
Build Information:
Version 1.0.5 (SVN Rev 26954)
Copyright 1998-2008 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.12.8, with GLib 2.14.6, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with ADNS, with Lua 5.1, with GnuTLS 2.3.8, with Gcrypt 1.4.1, with MIT
Kerberos, with PortAudio V19-devel, with AirPcap.
Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
--
I believe tcp.analysis.rtt_ack analysis should be based upon the FIRST time
that the TCP payload receiver acks the payload received. The wireshark
analysis however seems to be that subsequent packets from the acking system
that have the same ack-byte value are reported as very long rtt_acks instead of
being ingnored as not-first acks. If no additional data has been
transmitted/recieved, it is normal for the ack value to be repeated. It seems
like this should be separated the rtt_ack calculation of the first ack which
would show the true rtt_ack value.
In attached pcap file:
Packet 2: TCP port 26337 sends 4 byte TCP payload
Packet 3: TCP port 11012 acks receipt, wireshark correctly calculates rtt_ack
Packet 4: TCP port 11012 sends 4 byte TCP payload while maintaining previous
ACK value - Wireshark incorrectly interprets this as a very long rtt_ack time
for packet 2. Packet 2 was acked by packet 3... not 4. The long rtt_ack
reported in wireshark analysis of packet 4 incorrectly implies the presence of
rtt or ack issues.
I am afraid that I discarded most of my ethereal setup files when I moved to
wireshark. An old Ethereal 0.9.16 shows a correct tcp.analysis.rtt_ack in
packet 3 and correctly shows no rtt_ack analysis in 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.