Created attachment 1319198 [details]
Example data for libpcap bug
Description of problem:
If libpcap1.8 encounters a pcap file with the snaplen specified as larger than the default value of 262144 bytes, it refuses to open it. In earlier versions these files would open without any issue. This should not be a fatal error, as it's for instance a common use case for traffic capture using memory-mapped files.
Version-Release number of selected component (if applicable):
Create a pcap file with snaplen > 262144 (example file in the attached tarball). Attempt to tcpreplay or editcap or mergecap the file. Under earlier versions of the library, it will work just fine. Under 1.8 it will fail.
Steps to Reproduce:
1. tar xvfj example.tar.bz2
2. tcpreplay -i <interface-name> -x 100.0 bad-pcap-replay.pcap
Failed: Error opening pcap file: invalid file capture length 33554392, bigger than maximum of 262144
Actual: 73337 packets (7790535 bytes) sent in 3.01 seconds. Rated: 2588217.5 bps, 19.75 Mbps, 24364.45 pps
Statistics for network device: ens6f1
Attempted packets: 73337
Successful packets: 73337
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
Googling suggests that there was a documentation change in 2015 to change the default value from 64K to 256K.
thanks for your report.
I did a quick check of the libpcap source code and this seems like a work for upstream, because they specify the maximum value directly in the source code:
$ grep -B 20 MAXIMUM_SNAPLEN pcap-int.h
* Maximum snapshot length.
* Somewhat arbitrary, but chosen to be:
* 1) big enough for maximum-size Linux loopback packets (65549)
* and some USB packets captured with USBPcap:
* (> 131072, < 262144)
* 2) small enough not to cause attempts to allocate huge amounts of
* memory; some applications might use the snapshot length in a
* savefile header to control the size of the buffer they allocate,
* so a size of, say, 2^31-1 might not work well.
* We don't enforce this in pcap_set_snaplen(), but we use it internally.
#define MAXIMUM_SNAPLEN 262144
But there is definitely a regression between the old version and the new one. I can reproduce this issue using RHEL(CentOS)6:
user @ RHEL 6.8:~ $ rpm -q libpcap
user @ RHEL 6.8:~ $ rpm -q tcpdump
user @ RHEL 6.8:~ $ tcpdump -r bad-pcap-replay.pcap | tail
reading from file bad-pcap-replay.pcap, link-type EN10MB (Ethernet)
17:39:59.883324 IP 10.18.6.3.54513 > 18.104.22.168.21003: UDP, length 20
17:39:59.896614 IP 10.18.6.5.42707 > 22.214.171.124.21004: UDP, length 20
17:39:59.912502 IP 10.128.2.254 > reserved: ip-proto-253 46
17:39:59.931083 IP 10.18.6.7.49860 > 126.96.36.199.21005: UDP, length 20
17:39:59.933315 IP 10.18.6.3.54513 > 188.8.131.52.21003: UDP, length 20
17:39:59.946679 IP 10.18.6.5.42707 > 184.108.40.206.21004: UDP, length 20
17:39:59.962518 IP 10.128.2.254 > reserved: ip-proto-253 46
17:39:59.981088 IP 10.18.6.7.49860 > 220.127.116.11.21005: UDP, length 20
17:39:59.983450 IP 10.18.6.3.54513 > 18.104.22.168.21003: UDP, length 20
17:39:59.996432 IP 10.18.6.5.42707 > 22.214.171.124.21004: UDP, length 20
and Fedora 26:
user @ f26 $ rpm -q libpcap
user @ f26 $ rpm -q tcpdump
user @ f26 $ tcpdump -r bad-pcap-replay.pcap
tcpdump: invalid file capture length 33554392, bigger than maximum of 262144
user @ f26 $
It does seem a rather arbitrary / low limit, especially given that for instance the various sysctl net.core & net.ipv4 rmem limits typically max out at 16777216 or so.
This also breaks Bustle (which records logs in pcap format), because the maximum D-Bus message size is 128MiB. libpcap master now supports varying the maximum snaplen based on the link-layer type field, with one special-case for DLT_DBUS (and all other link types using MAXIMUM_SNAPLEN). Sadly these are not in any release yet:
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.
Fixed in current release of libpcap(1.9.0).