editcap issue when splitting files with periods of little activity
Summary
I am experiencing an issue with editcap. I have found that editcap does not split the input file as expected when it encounters periods with very little data ie 0 to a couple of packets per second. I have found this issue when splitting into 1 sec chunks but this issue still exists with other chunk sizes. I would have expected that if a given 1 sec chunk contained no data I would either get an empty .pcapng file for the given time period or I would get no .pcapng at all. However what I actually get is something quite different. I have created a sample file where some ping commands have been made first with a continuous ping and then I manually started/stopped/started etc. ICMP capture filter applied to limit the capture to only the test traffic.
Wireshark says Sample.pcapng lasts 26.249 seconds yet editcap creates x29 1 second files. For example editcap creates the following output files (all files attached)-
- 09:59:16 to 09:59:28 = OK
- Then creates an additional 09:59:28
- Skips 09:59:29 and 30
- Then creates x3 09:59:31 files
- and so on.
I should add that it is not the case that a missing file equates to a period with no packets since some of the files when opened contain no packets (for example output_00013_20230513095931).
The editcap command used is in the format shown below. This command generated the output files attached
editcap C:\Test\Sample.pcapng C:\Test\output.pcapng -i 1
Further testing showed the size of the original file is not the issue. This has been tested with Wireshark version 3.6.3 and 4.0.4 and found to have the same issue.
Sample capture file
Sample capture file is attached along with the output files generated with the above editcap command.
output_00000_20230513095916.pcapng
output_00001_20230513095917.pcapng
output_00002_20230513095918.pcapng
output_00003_20230513095919.pcapng
output_00004_20230513095920.pcapng
output_00005_20230513095921.pcapng
output_00006_20230513095922.pcapng
output_00007_20230513095923.pcapng
output_00008_20230513095924.pcapng
output_00009_20230513095925.pcapng
output_00010_20230513095926.pcapng
output_00011_20230513095928.pcapng
output_00012_20230513095928.pcapng
output_00013_20230513095931.pcapng
output_00014_20230513095931.pcapng
output_00015_20230513095931.pcapng
output_00016_20230513095933.pcapng
output_00017_20230513095933.pcapng
output_00018_20230513095934.pcapng
output_00019_20230513095936.pcapng
output_00020_20230513095936.pcapng
output_00021_20230513095937.pcapng
output_00022_20230513095940.pcapng
output_00023_20230513095940.pcapng
output_00024_20230513095940.pcapng
output_00025_20230513095941.pcapng
output_00026_20230513095942.pcapng
Steps to reproduce
The trigger appears to be when editcap is used to split up sections of a file that contains few packets or no packets. Run the command below with the attached trace file.
editcap C:\Test\Sample.pcapng C:\Test\output.pcapng -i 1
What is the current bug behavior?
Erratic generation of output files (see attached output files).
- Sometimes more than one file for a given period is generated.
- Sometimes no file is generated
- Sometimes a single file as is expected is generated.
What is the expected correct behavior?
I would have expected that if a given chunk contained no data I would get an empty .pcapng file for the given time period. I would expect a sequential numbering of output files for the given time period which they cover.
Build information
Wireshark 3.6.3 (v3.6.3-0-g6d348e46)
Copyright 1998-2022 Gerald Combs gerald@wireshark.org and contributors. License GPLv2+: GNU GPL version 2 or later https://www.gnu.org/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) using Microsoft Visual Studio 2019 (VC++ 14.29, build 30139), with Qt 5.15.2, with libpcap, with GLib 2.66.4, with zlib 1.2.11, with Lua 5.2.4, with GnuTLS 3.6.3 and PKCS #11 (closed) support, with Gcrypt 1.8.3, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.44.0, with brotli, with LZ4 ...
Also tested with 4.0.4