Bug ID |
11693
|
Summary |
Qt Wireshark - I/O Graph does not plot last elements in interval
|
Product |
Wireshark
|
Version |
unspecified
|
Hardware |
x86
|
OS |
All
|
Status |
UNCONFIRMED
|
Severity |
Minor
|
Priority |
Low
|
Component |
Qt UI
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Created attachment 13991 [details]
Small capture file with 10 very short TCP sessions separated by 61 seconds
Build Information:
Version 2.1.0-514-g412ab83 (v2.1.0rc0-514-g412ab83 from unknown)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 Qt 5.3.2, with libpcap, without POSIX capabilities, with
libz 1.2.5, with GLib 2.36.0, with SMI 0.4.8, without c-ares, without ADNS,
with
Lua 5.2, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP,
with QtMultimedia, without AirPcap.
Running on Mac OS X 10.10.5, build 14F1021 (Darwin 14.5.0), with locale C, with
libpcap version 1.5.3 - Apple version 47, with libz 1.2.5, with GnuTLS 2.12.19,
with Gcrypt 1.5.0.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)
Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.9.00).
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Qt Wireshark's I/O Graph does not plot the elements in the last unit of the
selected time Interval.
This issue has been seen on both OS X and Windows.
Steps to reproduce:
1 - Start Qt Wireshark.
2 - Load the first of the four attached four example capture files
(10TcpSessionsEachSeparatedBy61Seconds.pcapng).
3 - Open the I/O Graph dialog (menu: Statistics / I/O Graph).
With the default I/O graphs of "All packets" and "TCP errors" enabled you
should see several 13 packet/sec spikes. Each of the spikes represents one of
the TCP sessions. But only 9 of the 10 sessions are graphed; the 10th session
is not graphed.
4 - Change the graph's Interval to 10 seconds.
We still only see 9 of the 10 TCP sessions, but with 10 second Interval we can
now see that there were 4 TCP errors for each TCP session.
5 - Change the graph's Interval to 1 minute.
The artifact of using a line graph now shows the All Packets as flat line at
13, and a series of bar graphs (that look like an impulse graph) for the TCP
errors. Again the 10th TCP session is not graphed.
6 - Change the graph's Interval to 10 minutes.
Now NO elements are graphed.
7 - Repeat this exercise with the less than 1 second Interval values and note
that with the 0.0001 second Interval that only TCP conversations up to about
the 244 second are plotted.
At this time resolution (0.0001 seconds per interval)with a trace file of this
duration (549 seconds) we run out of maximum graph points (250000) before we
run out of graph-able data. A related issue is that currently there is no
method to graph data beyond the 250th second at this time resolution. Should
the I/IO graph's status message field warn the user that not all data was
plotted?
Note: Each of the four attached capture files started from the same capture
with 10 non-overlapping short (13 packet) TCP sessions separated by
approximately one second intervals. For the other three capture files the
inter-packet duration for each TCP session was maintained while the
inter-session time gap was edited to help expose time Interval related
artifacts of the I/O Graph.
Repeating the steps above with the captures with the smaller and larger total
time durations will help expose some of the I/O Graph artifacts when using
capture files of various durations at various time resolutions using the
various graph types. For example the BAR style graph for the TCP errors
displays wider and wider as time the time resolution gets finer.
You are receiving this mail because:
- You are watching all bug changes.