https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6081
Summary: patch calculation of tcp.analysis.ack_lost_segment
Product: Wireshark
Version: 1.6.0
Platform: x86-64
OS/Version: SuSE
Status: NEW
Severity: Normal
Priority: Low
Component: TShark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: gyorgy.szaniszlo@xxxxxxxxxxxx
Build Information:
TShark 1.6.0 (SVN Rev Unknown from unknown)
Copyright 1998-2011 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 (64-bit) with GLib 2.22.1, with libpcap 1.1.1, with libz 1.2.3,
without
POSIX capabilities, without libpcre, without SMI, without c-ares, without ADNS,
without Lua, without Python, without GnuTLS, without Gcrypt, without Kerberos,
without GeoIP.
Running on Linux 2.6.33.2-0.1-moniq, with libpcap version 1.1.1, with libz
1.2.3.
Built using gcc 4.4.1 [gcc-4_4-branch revision 150839].
--
A short intruduction (motivation) to the BUG:
I would like to use WireShark (tshark) to estimate packet loss on pcap file(s).
Only TCP data packet loss is analyzed, lost ACK packets are not detected.
Packet loss can happen in two different locations:
- Network-side: packet was lost in the monitored network itself
- Monitoring-side: packet was present in the monitored network,
but lost in the monitoring infrastucture (spam port, tap, sniffer machine)
- Total packet loss = Network-side + Monitoring-side
WireShark provides two different TCP data packet loss indicator flags:
- tcp.analysis.lost_segment: A segment before this one was lost
this flag fires for both kind of packet loss (network- and monitoring-side)
it provides the Total packet loss estimation
- tcp.analysis.ack_lost_segment: This frame ACKs a lost segment
this flag fires only for monitoring-side packet loss (but not in all cases)
if it fires, it is strong evidence for monitoring-side packet loss
It is very important, to be able to differentiate the monitoring-side packet
loss (measurement error), from the real network-side packet loss.
tcp.analysis.ack_lost_segment would be a perfect indicator for this.
Further reading:
http://smusec.blogspot.com/2010/06/flushing-out-leaky-taps.html
Now here comes the BUG:
I have executed the following test (test-A):
Picked up a normal trace, without any packet loss (test-A_trace-1_normal.pcap),
and manually deleted packet nr 50 (test-A_trace-2_missing-packet-nr-50.pcap).
With this I tried to simulate monitoring-side packet loss.
Checking the modified trace file with tshark,
+ it reported tcp.analysis.lost_segment for packet 50. This is OK.
- but it did not report tcp.analysis.ack_lost_segment for 51. This is wrong.
Packet 51 is an ACK packet, it ACKed the lost segment, that I have deleted.
tcp.analysis.lost_segment indicator should fire for packet 51!
I have checkek the source code (epan/dissectors/packet-tcp.h, packet-tcp.c).
The root cause of the bug is the following.
tcp.analysis.lost_segment and tcp.analysis.ack_lost_segment shoul be two
independent indicators, but they are coupled in the following way:
Both indicators uses the same tcp state variable (nextseq) to detect their
condition.
The detection and handling of tcp.analysis.lost_segment (that happens on data
packets, tipically 1-2 packets before the ACK packet)
modifies the tcp state variable, and supresses the 1-2 packet later detection
of tcp.analysis.ack_lost_segment.
Proposed patch:
I have introduced a new tcp state variable: maxseqtobeacked, this is the
maximum seq number that can be acked by the rev party in normal case.
This new state variable only serves the proper detection of
tcp.analysis.ack_lost_segment indicator, and decouples it from the detection of
tcp.analysis.lost_segment indicator.
The patched tshark shows both indicators:
+ tcp.analysis.lost_segment for packet 50
+ tcp.analysis.ack_lost_segment for packet 51
In case of monitoring-side packet loss, both indicator should fire.
In case of 'normal' network-side packet loss, only tcp.analysis.lost_segment
should fire.
Some more testing:
To demonstrate this, I have executed the following test (test-B):
I have picked up a 'normal' trace with network-side packet loss
(test-B_trace-1_network-side-packet-loss.pcap).
The packet loss is detected by tshark:
packet nr 58 [TCP Previous segment lost]
(both the original and the patched tshark did the same)
and it was also detected by the rec and fwd party of the tcp flow,
and the lost segment was successfully retransmitted in packet 60 [TCP
Retransmission].
Now I have spoiled this trace with monitoring-side packet loss, removing packet
27 (test-B_trace-2_missing-packet-nr-27.pcap).
Original tshark reported the following indicators:
packet nr 27 [TCP Previous segment lost]
packet nr 57 [TCP Previous segment lost]
Patched tshark reported the following indicators:
packet nr 27 [TCP Previous segment lost]
packet nr 31 [TCP ACKed lost segment]
packet nr 57 [TCP Previous segment lost]
Perfect, this is exactly what I wanted to achieve!
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.