https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6208
Summary: Status bar count of displayed packets wrong
Product: Wireshark
Version: 1.7.x (Experimental)
Platform: x86
OS/Version: Windows Vista
Status: NEW
Severity: Normal
Priority: Medium
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: Jim@xxxxxxxxxxxxxxxxx
Created an attachment (id=6782)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=6782)
Screen shot "Displayed Packets.jpg" showing status bar displayed packet count
error.
Build Information:
Version 1.7.0-SVN-38344 (SVN Rev 38344 from /trunk)
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 (32-bit) with GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
unknown), with libz 1.2.5, without POSIX capabilities, with threads support,
without libpcre, with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without
Python, with GnuTLS 2.10.3, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP,
with PortAudio V19-devel (built Aug 4 2011), with AirPcap.
Running on 32-bit Windows Vista Service Pack 2, build 6002, with WinPcap
version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.10.3, Gcrypt 1.4.6, with AirPcap 4.1.1 build
1838.
Built using Microsoft Visual C++ 9.0 build 21022
--
During large live captures with a display filter in place, the status bar count
of displayed packets can be too high and can actually show more displayed
packets than captured packets.
I was doing a live capture with a 100,000 packet stop condition in place. Near
the end of the capture (more than 92,000 packets captured), I applied the
following display filter: “!ip.addr==10.29.152.74”
As the capture progressed, I watched the status bar and noted that the count of
displayed packets was higher than the count of total packets. Because of a typo
in my display filter (it should have been “10.29.153.74”), there were no
matching packets, so the count of displayed packets should have been equal to
the count of total packets.
When the capture stopped at 100,000 packets, the status bar showed 100,000
total packets, and 100,027 displayed packets. See the attached file “Displayed
Packets.jpg” for a screen shot of the status bar display. When I cleared the
display filter, the count of displayed packets corrected itself to 100,000.
When I re-applied the filter, the count of displayed packets stayed correct.
I started another live capture and repeatedly applied and cleared the display
filter while the capture was in progress. The displayed packet count matched
the total packet count until more than 75,000 packets had been captured. After
that point, applying the display filter caused the displayed packets count to
be higher than the total packets count, and clearing the display filter caused
the displayed packets count and total packets count to be equal again. Once the
error appeared, applying the display filter would usually--but not
always--cause the error. Occasionally the displayed packet count and total
packet count stayed in sync when the display filter was applied.
Once the live capture was stopped, applying the display filter no longer caused
the error.
I repeated the test from another location where I was able to download
streaming video, resulting in a much higher packet rate. Under the higher
packet rate, the error showed up much sooner (around 42,000 packets), and the
difference was much larger. When 100,000 total packets had been captured, the
displayed packets count was 100,894.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
