Created attachment 15654
sample pcapng to reproduce bug in Packet Lengths
Build Information:
Version 2.2.7 (v2.2.7-0-g1861a96b)
Copyright 1998-2017 Gerald Combs <gerald@wireshark.org> 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.6.1, with WinPcap (4_1_3), with GLib 2.42.0, with
zlib 1.2.8, with SMI 0.4.8, with c-ares 1.12.0, with Lua 5.2.4, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale
English_United States.1252, with WinPcap version 4.1.3 (packet.dll version
4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), with
GnuTLS 3.2.15, with Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz (with SSE4.2), with 32392MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 40629
STEPS TO REPRODUCE:* load jumbo_frame_sample_anon.pcapng (attached)* Statistics->Packet LengthsOBSERVATIONS:* Displays correct data for "all packets" in its totals* Does not display any data for packets of '5120 or greater' bytes.* However, the count of '5120 or greater' packets IS included in the percentage calculations.TESTING TO DATE:* Using a display filter of 'frame.len > 5119' within Statistics->Packet Lengths yields correct totals, but still no details on the '5120 or greater' line.* Using a display filter of 'frame.len > 5119' functions as expected in Wireshark proper.* Testing with 'tshark -nr jumbo_frame_sample_anon.pcapng -T fields -e frame.len | sort -n | uniq -c' functions as expected.* Problem occurs across operating systems (Win7 & Ubuntu), across builds (2.2.7 and 2.2.6), and across GUIs (occurs in both Qt and GTK+ GUIs)PRELIMINARY CONCLUSION:Since the data for large packets is included in the totals for Packet Lengths and the percentage calculations - and since both Wireshark and tshark can dissect/display/manipulate the large packets in other ways - I don't think this is a bug in the dissection engine. This looks like a bug specific to Statistics -> Packet Captures.